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ABSTRACT 


The  design  and  execution  of  a  networked  virtual  environment  (NVE)  are 
challenging  tasks  made  even  more  difficult  by  the  fact  that  NVEs  are  becoming  more 
complex  and  difficult  to  manage.  In  a  distributed  environment,  each  simulation  not  only 
computes  its  own  behaviors  and  publishes  them  to  the  network,  but  it  must  accurately 
represent  all  other  entities  participating  in  the  NVE.  To  simplify  this  task,  this  thesis 
implements  method  to  make  distributed  simulations  dynamically  extensible,  flexible, 
specific,  and  consistent.  Bamboo  provides  the  ability  to  dynamically  extend  the  virtual 
environment  by  defining  a  convention  by  which  plug  in  modules  can  be  added  during 
simulation  runtime.  The  HLA  provides  the  network  communication  layer  that  transports 
entity  state  updates  to  all  members  of  the  distributed  simulation.  These  two  tools  combine 
to  create  a  unique  solution  to  problems  inherent  in  designing  modem  networked  virtual 
environments.  The  implementation  is  dynamically  extensible  which  increases  the  flexibility 
implementers  have  in  designing  virtual  environments.  The  HLA  transports  the  entity 
updates  and  the  module  name  that  must  be  used  to  represent  the  entity.  This  method 
allows  programmers  to  design  only  their  module  because  modules  representing  other 
entities  will  load  as  needed  during  the  execution.  This  method  of  implementing  virtual 
environments  that  promises  to  streamline  the  design  and  implementation  process. 
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I.  INTRODUCTION 


A.  MOTIVATION 

The  design  and  execution  of  a  networked  virtual  environment  (NVE)  are 
challenging  tasks  made  even  more  difficult  by  the  fact  that  NVEs  are  becoming  more 
complex  and  difficult  to  manage.  In  a  distributed  environment,  each  simulation  not  only 
computes  its  own  behaviors  and  publishes  them  to  the  network,  but  it  must  accurately 
represent  all  other  entities  participating  in  the  NVE.  To  simplify  this  task,  a  method  must 
be  devised  to  make  distributed  simulations  dynamically  extensible,  flexible,  specific,  and 
consistent.  A  dynamically  extensible  virtual  environment  would  allow  users  to  change  the 
executable  at  runtime  to  whatever  state  is  specified  by  the  user.  The  challenge  is  to  design 
a  system  that  allows  users  to  design  entity  definitions  that  can  be  loaded  and  unloaded 
during  execution.  With  true  dynamic  extensibility  comes  flexibility,  and  designers  are  not 
tied  to  compile  time  determinations  of  behavior.  Consistency  in  this  sense  means  all  sites 
participating  in  the  NVE  need  the  same  definitions  for  each  entity  and  the  terrain  model 
being  used.  Finally,  the  designer  of  a  specific  simulation,  such  as  a  tank  simulator,  should 
not  need  to  design  the  other  entities  that  will  be  depicted  in  the  simulation.  These  remote 
objects  should  be  program  objects  that  can  be  added  as  needed  during  execution.  This 
approach  will  allow  NVE  implemented  and  programmers  the  flexibility  to  design  and  run 
NVEs  in  real  time  without  the  problems  of  inflexibility  and  static  design  inherent  to 
distributed  simulation. 

B.  BACKGROUND 

There  are  many  examples  of  NVEs  that  use  different  methods  of  communicating 
entity  state  and  ensuring  consistency  between  simulation  locations.  Examples  include 
DIVE  [1]  and  BRICKNET  [2].  These  systems  share  one  characteristic.  They  are  defined 
at  compile  time  and  are  unchangeable  during  execution.  They  allow  dynamic  allocation  of 
memory  but  the  definitions  of  each  entity  are  defined  at  compile  time  and  are 
unchangeable. 

The  DIVE  core  uses  peer-to-peer  communication  between  shared  virtual  worlds. 
All  DIVE  processes  connected  to  the  same  world  are  identical.  A  DIVE  process  can 
choose  what  world  it  is  a  part  of  but  it  can  only  be  a  member  of  one  world  at  a  time. 
DIVE  is  limited  by  the  paradigm  of  distributed,  shared  memory.  This  paradigm  creates 
significant  network  traffic  trying  to  keep  the  shared  memory  consistent  from  process  to 
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process.  While  DIVE  shared  virtual  worlds  may  change  during  runtime,  the  method  of 
communication  and  the  abilities  of  the  system  are  previously  defined  and  are  not  extensible 
at  runtime. 

BRICKNET  allows  the  exchange  of  objects  and  object  updates  through 
BRICKNET  servers.  While  it  does  distribute  processing  on  multiple  servers,  entities 
require  the  server  to  update  state  and  define  behavior.  Workstations  are  primarily  used  to 
render  the  graphics  for  the  user.  Furthermore,  BRICKNET  object  updates  are  predefined 
and  the  update  protocol  cannot  be  modified. 

Finally,  distributed  interactive  systems  (DIS)  like  NPSNET  [3]  are  designed  on  the 
premise  that  each  site  could  build  their  own  simulation  and  choose  how  to  represent  each 
type  of  entity  without  regard  to  the  consistency  of  this  representation  across  the  network. 
Each  site  could  have  its  own  terrain  model  and  its  own  representations  for  each  entity 
type.  Because  of  these  inconsistencies,  DIS  simulations  are  plagued  with  discrepancies 
between  entity  position  and  orientation  and  line  of  site  computations  related  to  the  terrain 
models.  DIS  is  highly  enumerated  and  the  packets  containing  entity  state  are  large  and 
mostly  redundant.  These  inconsistencies  complicate  interactions  between  entities  because 
the  terrain  may  provide  different  line  of  sight  computations  from  one  simulation  to  the 
next.  Additionally,  the  actual  polygonal  representation  and  behaviors  of  the  entity  may  not 
be  consistent  among  workstations  in  the  distributed  simulation.  This  causes  excess 
network  traffic  to  solve  simple  interactions  between  entities  and  keep  entity  state  updated 
accurately  between  simulation  sites. 

Until  now,  there  was  no  way  to  ensure  all  simulation  sites  had  the  proper 
polygonal  and  behavioral  representation  for  all  entities  participating  in  the  virtual 
environment.  A  new  system.  Bamboo  [4],  provides  such  a  capability  by  providing 
simulations  a  framework  to  dynamically  load  and  unload  program  modules  as  the  situation 
changes  in  the  virtual  environment.  High  Level  Architecture  (HLA)  [5]  replaces  DIS  and 
provides  the  network  communication  capabilities.  By  implementing  the  simulation  as  a 
group  of  program  modules,  designers  solve  the  problem  of  ensuring  that  every  site  running 
in  the  NVE  is  consistent  with  every  other.  The  designer  just  ensures  every  participant  in 
the  NVE  knows  the  network  location  of  all  the  program  modules  making  up  the  NVE. 
Then,  as  the  virtual  world  executes,  each  site  loads  and  unloads  modules  as  needed.  All 
simulation  sites  have  the  same  representations  for  each  entity  as  well  as  its  associated 
behaviors  and  controls. 

This  thesis  describes  an  implementation  that  uses  Bamboo  to  handle  the  dynamic 
nature  of  modem  NVEs,  and  HLA  to  handle  the  communication  between  each  simulation 
site.  The  following  sections  provide  an  overview  of  Bamboo  and  HLA  features  and  how 

2 


they  apply  to  this  implementation.  Later  chapters  provide  a  detailed  description  of  both 
systems. 

C.  BAMBOO 

Bamboo  enables  dynamically  scaleable  virtual  environments  hosted  on  a  network. 
It  achieves  this  goal  by  an  efficient  implementation  that  provides  direct  support  for  the  key 
issues  pertaining  to  VE  development.  These  issues  include  dynamic  extensibility,  module 
dependency,  and  event  handling  [4].  Bamboo’s  most  notable  feature  is  its  ability  to 
dynamically  extend  its  capabilities  during  run  time.  It  achieves  this  goal  by  implementing  a 
plug-in  metaphor  similar  to  that  used  by  commercial  packages  like  Photoshop  [6]  and 
Netscape  [7].  In  addition  to  the  plug-in  metaphor.  Bamboo  implements  a  system  that 
allows  the  user  to  extend  the  executable  through  a  series  of  callbacks  that  a  newly  added 
module  allocates  at  load  time.  The  event  handler  simply  provides  an  abstraction  for 
handling  system-generated  events.  The  event  handler  uses  the  callback  handler  to  notify 
registered  parties  of  an  event.  Bamboo  receives  this  notification  as  a  callback.  Module 
dependency  provides  a  system  to  ensure  that  modules  which  are  required  by  other 
modules  are  loaded  first  before  the  depending  module.  Bamboo  uses  callback  handlers  so 
multiple  callbacks  respond  to  a  single  event.  This  is  a  cursory  introduction  to  the  features 
and  capabilities  of  Bamboo.  Chapter  two  provides  a  detailed  description  of  the  Bamboo 
system. 

D.  HIGH  LEVEL  ARCHITECTURE 

The  High  Level  Architecture  (HLA)  is  the  Department  of  Defense  standard  for 
simulation  interoperability  [5].  HLA  is  not  software.  It  is  an  architecture  that  provides 
standard  methods  of  defining  how  distributed  simulations  will  communicate.  It  is  a  set  of 
specifications  that  define  data  objects.  These  standards  are  specified  in  the  HLA  Interface 
Specification  and  the  Object  Model  Template  (OMT).  The  HLA  Interface  Specification 
defines  the  interface  between  the  simulation  and  the  software  that  will  provide  the  network 
and  simulation  management  services.  The  Runtime  Infrastructure  (RTI)  is  the  software 
that  provides  these  services.  The  OMT  prescribes  a  common  method  for  recording  the 
information  that  will  be  produced  and  communicated  by  each  simulation  participating  in 
the  distributed  exercise.  This  discussion  of  HLA  is  continued  in  detail  in  Chapter  3. 

E.  THESIS  ORGANIZATION 

This  thesis  is  organized  into  the  following  chapters: 
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•  Chapter  I:  Introduction.  Outlines  the  organization  of  the  thesis  and  addresses 
the  significance  of  introducing  and  evaluating  a  new  method  for  implementing 
a  networked  virtual  environment. 

•  Chapter  II:  Bamboo.  Discusses  in  detail  the  current  implementation  of 
Bamboo  and  how  its  capabilities  are  suited  for  a  networked  virtual 
environment  implementation. 

•  Chapter  HI:  High  Level  Architecture.  Discusses  in  detail  the  current 
implementation  of  the  HLA  and  how  its  capabilities  are  suited  for  a  networked 
virtual  environment  implementation.  This  chapter  includes  a  detailed 
discussion  of  the  run  time  infrastructure  (RTI)  and  how  its  capabilities  are 
exploited  in  this  implementation. 

•  Chapter  IV:  Implementation.  Describes  the  development  of  the  experimental 
virtual  environment  that  illustrates  the  power  of  combining  Bamboo  and  HLA. 

•  Chapter  V:  Results  and  Limitations.  Describes  performance  results  for  the 
implementation  and  certain  limitations  discovered  during  development. 

•  Chapter  VI:  Conclusions  and  Recommendations.  Discusses  the  significance  of 
the  results  and  gives  ideas  as  to  future  work  that  should  be  completed  in  this 
area. 
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H.  BAMBOO 


A.  INTRODUCTION 

Bamboo  enables  dynamically  scalable  virtual  environments  hosted  on  a  network 
[4].  It  achieves  this  goal  by  an  efficient  implementation  that  provides  direct  support  for 
the  key  issues  pertaining  to  VE  development.  These  issues  include  dynamic  extensibility, 
event  handling,  and  module  dependency.  By  addressing  these  issues,  Bamboo  provides 
the  ability  for  the  system  to  dynamically  configure  itself  during  runtime.  Specifically,  this 
framework  provides  the  ability  to  discover  simulation  objects  on  the  network  at  runtime 
and  automatically  load  the  correct  module  to  represent  the  entity. 

B.  DYNAMIC  EXTENSIBILITY 

Bamboo’s  most  notable  feature  is  its  ability  to  dynamically  extend  its  capabilities 
during  run  time.  It  achieves  this  goal  by  implementing  a  plug-in  metaphor,  then  extends 
the  idea  by  adding  module  dependency,  a  generalized  method  of  extending  the  executable 
and  a  generalized  event  handler. 

1.  Dependency 

Bamboo  extends  the  plug-in  metaphor  by  adding  inter-module  dependencies. 
Tracking  inter-module  dependencies  could  be  complex.  Fortunately,  as  Bamboo  loads 
each  module,  it  verifies  that  dependent  modules  load  first.  If  they  are  not  loaded,  it 
automatically  loads  them  without  specific  interaction  with  the  user.  Using  Figure  1  as  an 
example,  assume  M3  is  already  loaded.  If  M4  loads  later,  the  system  verifies  the  presence 
of  M2  in  memory.  Bamboo  loads  M2  if  it  is  not  in  memory.  As  M2  is  being  loaded 
Bamboo  verifies  the  presence  of  Ml.  M4  finally  loads  because  Bamboo  verified  all  its 
dependencies  [4]. 
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2.  Extending  the  Executable 

Dynamic  loading  of  program  modules  does  not  in  itself  ensure  dynamic 
extensibility.  Bamboo  uses  a  callback  handler  that  allows  each  module  to  attach  and 
remove  itself  from  the  process’s  execution  loop  when  being  paged  in  and  out  of  memory. 
The  callback  handler  derives  from  objects  that  can  be  named  so  it  is  easily  located  and 
manipulated.  The  callback  itself  is  recursive  and  provides  two  callback  handlers,  one  just 
before  callback  execution  and  one  directly  after.  This  allows  grouping  of  like 
functionality.  For  example,  rendering  engines  implement  some  form  of  app,  cull  and  draw 
as  a  pipeline.  Users  refer  to  surrounding  areas  as  pre  and  post  app,  pre  and  post  cull,  and 
pre  and  post  draw.  The  executable  begins  to  resemble  a  tree  of  callbacks.  Figure  2 
illustrates  how  using  callbacks  and  callback  handlers  to  extend  the  executable  begins  to 
resemble  a  tree  of  callbacks.  For  instance,  a  user  module  may  load  itself  and  depend  to 
the  visual  and  keyboard  modules.  At  load  time,  the  user  module  defines  callbacks  that 
provide  execution  time  for  the  logic  in  the  module.  Furthermore,  any  pruning  or  pausing 
of  sub-trees  automatically  includes  its  children.  Therefore  if  a  callback  handler  is  deleted, 
all  of  its  associated  callbacks  are  also  deleted  without  specific  user  interaction. 
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Figure  2:  Extending  the  Executable 

3.  Event  Handling 

The  event  handler  simply  provides  an  abstraction  for  handling  system-generated 
events.  The  event  handler  uses  the  callback  handler  to  notify  registered  parties  of  an 
event.  Bamboo  receives  this  notification  as  a  callback.  Bamboo  uses  callback  handlers  so 
multiple  callbacks  respond  to  a  single  event.  For  example,  a  module  that  captures 
keyboard  events  would  monitor  the  keyboard  in  a  separate  thread  listening  for  keys 
identified  by  the  user.  In  figure  2,  the  Event  Handler  Module  has  multiple  callbacks  on 
two  separate  keys.  When  a  key  is  pressed,  then  the  callbacks  are  executed  in  the  order 
specified. 

C.  BAMBOO  CONCLUSION 

Bamboo  improves  on  the  plug-in  metaphor  in  three  distinct  ways.  It  provides  a 
convention  for  the  definition  of  program  modules.  Second,  it  generalizes  a  method  to 
extend  the  executable,  and  third,  it  provides  a  method  to  build  dependencies  between 
modules.  Using  these  features.  Bamboo  overcomes  many  of  the  pitfalls  of  monolithic 
virtual  environment  architectures  by  providing  modular  components  and  a  dynamically 
extensible  runtime  executable. 
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m.  HIGH  LEVEL  ARCHITECTURE 


A.  INTRODUCTION 

The  High  Level  Architecture  (HLA)  provides  a  common  architecture  for  reuse  and 
interoperation  of  simulations.  This  means  that  simulations  designed  for  a  specific  purpose 
may  be  reused  in  a  different  application  using  the  HLA  concept  of  a  federation:  a 
composable  set  of  interacting  simulation  participants  -  federates.  The  intent  is  to  provide 
a  standard  architecture  under  which  simulations  are  designed  so  that  they  can  be  reused 
thereby  reducing  the  time  and  cost  required  creating  a  new  environment  for  a  new 
purpose.  [5] 

The  Object  Model  template  (OMT)  [8],  HLA  rules  [9]  and  the  Interface 
Specification  (IF  Spec)  [10]  define  the  HLA  standard.  A  final  component  of  the  HLA  is 
the  Runtime  Infrastructure  (RTI).  The  OMT  describes  the  essential  sharable  elements  of 
the  simulation  or  federation  in  ‘object’  terms.  In  the  HLA  sense,  objects  are  collections  of 
attributes  that  describe  simulation  entity  state  that  are  communicated  between  federates 
operating  in  the  federation.  Second,  the  IF  Spec  describes  the  runtime  services  provided 
to  each  federate  by  the  RTI.  The  RTI  is  the  software  component  of  the  HLA  that 
supports  the  exchange  of  data  defined  by  the  OMT  component.  Finally,  The  HLA  rules 
summarize  the  key  principles  behind  the  HLA. 

B.  OBJECT  MODEL  TEMPLATE 

The  HLA  is  designed  to  facilitate  interoperability.  Hence,  the  OMT  is  designed  to 
provide  a  means  for  open  information  sharing  across  the  simulation  community.  The 
OMT  does  not  constrain  the  content,  but  provides  a  streamlined  format  for 
communicating  to  the  other  users,  who  may  reuse  the  simulation,  and  the  data  inputs  and 
outputs  of  the  simulation.  The  HLA  specifies  two  types  of  object  models:  the  HLA 
Federation  Object  Model  (FOM)  and  the  HLA  Simulation  Object  Model  (SOM).  The 
FOM  is  a  specification  of  the  exchange  of  public  data  among  the  participants  in  a  HLA 
federation.  Those  participants  are  called  federates.  The  HLA  FOM  describes  the  set  of 
objects,  their  attributes  and  interactions  that  are  shared  between  federates  in  a  federation. 
The  SOM  describes  the  simulation  (federate)  in  terms  of  the  types  of  objects,  attributes, 
and  interactions  it  can  offer  to  future  federations. 
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1.  Federation  Object  Model 

The  FOM  requires  information  concerning  the  object  classes,  object  interactions, 
class  attributes,  interaction  parameters  and  a  lexicon  describing  each  of  the  above  [8]. 

a.  Object  Class  Structure  Table 

Each  object  class  must  be  named  and  its  relationship  to  other  classes  must 
be  defined.  All  classes  must  be  defined  and  described  in  the  lexicon.  The  result  is  a  table 
similar  to  Table  1  [8]. 


Object  Class  Structure  Table  j 

<elass>(<ps>) 

[<class>  (<ps>)} 

[<class>  (<p$>)1 

r<class>  (<ps>)l  ft<class>  (<ds>)1*I  [<refi>l  ! 

r<class>  (<ds>)1  r,<class>  (<ds>)1*I  r<ref>l 

[<elass>  (<p  s  >)] 

[<class>  (<ds>YI  f.<class>  (<ds>)1*I  r<re£>l 

i  ^ 

[<class>  (<ps>)] 

f<class>  (<ps>)l  [,<class>  (<ps>)l*i  f<ref>l 

- 

- 

- 

- 

Air  Vehicles) 

Fixed  Wing  (S) 

Fighter-Attack  (S) 

*06  (PS) _ 1 

Bomber  (S) 

■■■■■■ 

Table  1:  Object  Class  Structure  Table 

This  table  shows  the  object  model  used  in  a  federation.  Class  Air  Vehicle  is  the  base  class 
for  all  flying  entities.  Class  Fixed  Wing  and  Rotary  wing  inherit  from  Air  Vehicle,  while 
Fighter- Attack  and  Bomber  inherit  from  Fixed  Wing.  Then  F-14,  F-16,  etc.  describe  the 
specific  types  of  aircraft  depicted  in  the  federation.  The  (P),  (S)  and  (PS)  stand  for 
publishable,  subscribable  and  both,  respectively.  This  means  that  individual  federates  can 
request  -  subscribe  -  certain  object  attributes  from  the  federation.  A  federate  may  also 
provide  —  publish  -  object  attributes  to  the  federation.  If  a  federate  represents  an  entity 
that  must  interact  with  entities  of  the  same  type,  that  federate  might  publish  and  subscribe 
to  the  same  Object  Class. 
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b.  Object  Interaction  Table 

The  object  interaction  table  shows  the  interaction  class  structure  for  the 
federation.  Table  2  shows  the  interaction  class  structure  [8].  An  interaction  is  an  explicit 
action  taken  by  an  object  that  can  optionally  be  directed  toward  other  objects.  In  this 
case,  Weapon  Detonate  is  the  base  interaction  class,  and  Weapon  Detonate  at  Air  Target 
and  Weapon  Detonate  at  Ground  Target  are  both  inherited  from  Weapon  Detonate.  This 
table  also  lists  the  initiating  and  receiving  object  and  the  affected  attributes  for  each  object. 


|  Object  Interaction  Table 

Interaction  Structure 

Initiating  Object 

Receiving  C 

Ibject/Area 

Interaction 

Ink/ 

Sense/ 

React 

Class 

Affected 

Attributes 

Class 

Affected 

Attributes 

<mtoraction> 

I<interaction>] 

<ctess> 

[,<claa3>r 

[<attribute>] 

[,<attribute>r 

[(<comment>)]* 

[<dass>] 

[,<dass>J* 

[<attribute>] 

[,<attribute>j* 

[(<eomment>)]* 

[<param«ter>] 

[,<perameter»J' 

<isr> 

[<interaction>] 

<dase> 

[,<daea>J* 

[<attr’buta>] 

[,<attjft>ute>]* 

[(<comment>))* 

[<dass>] 

[,<dasa>r 

[<attribute>] 

|,<atthbute>r 

[(<connment>))* 

[<parameter>] 

[,  <p  era  mete  r>J* 

bbh 

SHESBH 

ooteractioro 

[interact  ion  >] 

<cla*s> 

[,<das3>r 

[<attribute>] 

[,<attributa>]* 

[(<comment>)J* 

[<dasa>] 

[,<dasa>r 

[<attribute>] 

[,<attribu1e>j* 

[(<comment>)l* 

[<paremeter>] 

L<parameter>r 

a 

■ 

■ 

u 

m 

IH 

■BH 

1 

Weapon 

Detonate 

Weapon  Detonate 
at  Air  Target 

Weapon 

Velocity, 

Acceleration, 

Weight. 

Air  Vehicle 

Velocity, 

Acceleration, 

Weight, 

Weapon  Location, 
Warhead, 
Weapon  Attitude. 

IR 

Weapon  Detonate 
at  Ground  Target 

... 

- 

... 

- 

- 

Table  2:  Object  Interaction  Table 

The  last  column  in  the  table  shows  the  three  basic  categories  of  interaction: 

•  Initiates  (I):  indicates  that  a  federate  is  currently  capable  of  initiating  and  sending 
interactions  of  the  type  specified  in  that  row. 

•  Senses  (S):  indicates  that  a  federate  is  currently  capable  of  subscribing  to  the  interaction 
and  utilizing  the  interaction  information,  without  necessarily  being  able  to  effect  the 
appropriate  changes  to  affected  objects. 

•  Reacts  (R):  indicates  that  federate  is  currently  capable  of  subscribing  and  properly 
reacting  to  the  interactions  of  the  type  specified  by  effecting  the  appropriate  changes  to 
any  owned  attributes  of  the  affected  objects. 

In  a  FOM  definition,  all  of  the  above  are  valid  entries.  There  would  not  be  a  listing  if 
there  was  not  a  federate  responsible  for  the  interaction. 
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a.  Attribute/Parameter  Table 

Finally,  the  Attribute/Parameter  Table  [8]  defines  characteristics  pertinent 
to  each  Class/Interaction  described  in  Table  1  and  Table  2.  Interactions  are  published  by 
and  subscribed  to  by  federates  depending  on  the  structure  of  the  federation.  Table  3  is  the 
Attribute/Parameter  Table  for  a  Tank  Object  and  the  Weapon  Detonate  Interaction.  For 
each  Object/Interaction  the 


Object/ 

Interaction 

Attribute/ 

Parameter 

Date 

Type 

Cardinality 

Unite 

Resolution 

Accuracy 

Accuracy 

Condition 

Update 

Type 

Update 

Condition 

T/A 

U/R 

<dass>  1 
<lrtefBCtiorc> 

<attribute>1 

<parameter> 

<datatype> 

[<size>] 

<units> 

<resokit»n> 

<accuraey> 

<oondkion> 

<type> 

<rate>  1 

<conditjon> 

<ta> 

<ur> 

<atiribute>l 

<parameter> 

<datatype> 

[<size>] 

<units> 

<resoiutk>rt> 

<accuracy> 

<condition> 

<type> 

<rate>  1 

<xondition> 

<ta> 

<ur> 

... 

[<size>] 

... 

<dass>  1 
<lnteraction> 

<attnbute>l 

<parameter> 

<datatype> 

(<size>] 

<units> 

<resokrtion> 

<accuracy> 

<condition> 

<type> 

<rate>  I 

<condrtKxi> 

<ta> 

<ur> 

<attribute>l 

<perameter> 

<datatype> 

[<size>] 

<units> 

<nesolution> 

<accuracy> 

<condftion> 

<type> 

<rate>  1 

<condrfen> 

<ta> 

<ur> 

... 

[<size>] 

... 

<class>  1 
clnteractkxo 

<attrfcute>l 

<perameter> 

<datatype> 

[<size>] 

<unrts> 

<resolutiort> 

<accuracy> 

<cofKfition> 

<type> 

<rate>  1 

<condrtion> 

<ta> 

<ur> 

... 

... 

... 

[<size>] 

... 

... 

-■ 

Tank 

Area 

Float 

1 

m2 

0.1  m2 

perfect 

always 

condhional 

seen  events 

TA 

UR 

Velocity 

Double 

1 

m/sec 

none 

periodk: 

10  Hz 

TA 

UR 

State 

Tank_Type 

1 

n/a 

n/a 

n/a 

n/a 

concfitbnal 

seen  events 

TA 

UR 

Position 

Rectng_Type 

1 

n/a 

n/a 

n/a 

periodic 

10Hz 

fa 

UR 

Weapon 

Detonate 

Warhead 

Wh_Type 

1 

n/a 

n/a 

n/a 

n/a 

n/a 

n/a 

■a 

n/a 

Table  3:  Attribute/Parameter  Table 


attributes  or  parameters  are  defined  and  characterized  by  multiple  descriptors  like  data 
type  and  units  of  measure.  The  second  to  last  column,  Transferable/Acceptable  refers  to  a 
federate’s  ability  to  transfer  or  accept  the  responsibility  to  update  the  specified  attributes 
for  a  particular  entity.  For  a  FOM,  the  only  acceptable  entries  are  (TA)  for 
Transferable/Acceptable  or  (N)  for  Not  Transferable/Acceptable.  The  last  column  refers 
to  a  federate’s  capability  to  update  (U)  and  reflect  (R)  attributes  or  parameters.  In  a 
FOM,  all  attributes  or  parameters  should  be  marked  both  updatable  and  reflectable. 
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2. 


Simulation  Object  Model 


A  FOM  is  the  union  of  all  SOMs  used  to  define  the  federation.  The  SOM  uses  the 
same  templates  as  the  FOM.  The  Object  Class  Table  in  Table  1  describes  the  object 
classes  represented  in  the  federation.  A  SOM  object  class  structure  table  would  designate 
which  classes  the  federate  publishes  (P)  and  which  it  has  the  capability  to  subscribe  (S). 
For  example,  the  F-16  federate  might  publish  the  F-16  object  and  subscribe  to  air  vehicle 
so  it  would  know  the  location  and  speed  of  all  other  aircraft  in  the  federation.  Similarly, 
the  Object  Interaction  table  would  differ  in  the  last  column  because  the  federate  must 
identify  what  interactions  it  has  the  capability  to  process.  The  F-16  federate  might  put  a 
(R)  in  the  last  column  of  Table  2  to  indicate  that  it  reacts  to  a  Weapon  Detonation  at  an 
Air  Target.  Additionally,  a  (I)  might  go  in  the  last  column  for  Weapon  Detonate  at 
Ground  Target  to  show  that  the  F-16  federate  initiates  the  interaction  to  fire  weapons  at  a 
ground  target.  Finally,  the  last  two  columns  in  the  Attribute/Parameter  Table  would  be 
modified  to  show  what  capabilities  the  federate  has  in  regards  to  its  ability  to  transfer  and 
accept  attributes  or  update  and  reflect  attributes. 

3.  FOM/SOM  Lexicon 

To  achieve  interoperability  between  simulations,  all  data  required  by  the  federation 
must  be  fully  explained.  It  is  not  enough  to  merely  specify  the  classes  of  data  required  by 
the  templates  above.  The  semantics  of  this  data  must  also  be  explained.  The  FOM/SOM 
Lexicon  provides  a  means  for  federations  to  document  the  definitions  of  all  terms  utilized 
during  construction  of  FOMs,  and  for  individual  federates  to  document  the  definitions  of 
all  terms  provided  in  their  SOMs. 

C.  INTERFACE  SPECIFICATION 

The  IF  Spec  [9]  describes  the  runtime  services  provided  to  the  federates  by  the 
RTI,  and  from  the  federates  to  the  RTI.  There  are  six  classes  of  service.  Each  defines  a 
specific  set  of  functions  that  pertain  to  a  particular  type  of  transaction  that  must  be 
accomplished  to  properly  manage  the  federation.  There  are  two  locations  where  the 
function  definitions  reside:  the  RTI  ambassador  and  the  federate  ambassador.  The  RTI 
ambassador  is  the  software  component  provided  by  HLA  and  contains  all  the  functionality 
required  to  accomplish  communication  to  the  network.  The  federate  ambassador  is  the 
RTI’s  interface  to  the  federate.  To  pass  data  to  the  federate,  the  RTI  ambassador  makes 
function  calls  to  a  user  defined  federate  ambassador.  The  RTI  ambassador  is  the  same  for 
all  federates  but  the  federate  ambassador  is  different  for  each  federate.  A  full  explanation 
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of  each  function  can  be  found  in  the  HLA  IF  Spec.  The  following  discussion  deals  mainly 
with  the  purpose  of  each  management  service. 

1.  Federation  Management 

Federation  management  services  offer  the  basic  functions  required  to  initiate  the 
federation,  add  federates  and  delete  federates  as  the  federation  finishes  execution.  These 
services  include  Create,  Join,  Pause/Resume,  Resign  and  Destroy  federation. 

2.  Declaration  Management 

Declaration  management  defines  the  services  required  to  support  efficient 
management  of  data  exchange.  It  does  this  by  providing  the  services  that  allow  federate’s 
to  identify  to  the  RTI  ambassador  the  object  and  interaction  classes  they  will  publish  and 
subscribe.  This  service  includes  Publish,  Subscribe,  and  Control  actions  on  specific  object 
classes  and  interactions. 

3.  Object  Management 

Object  management  services  refer  to  all  the  functions  required  to  manage  the 
update  of  object  attributes  during  federation  execution.  The  services  include  Request 
Object  ID  numbers.  Update  object  attributes.  Sending  Interactions,  Receiving  object 
updates.  Receiving  interactions,  Deleting  objects  and  Changing  transportation 
characteristics. 


4.  Ownership  Management 

Ownership  management  refers  to  the  dynamic  transfer  of  ownership  of  object 
attributes  during  federation  execution.  The  services  include  Request  attribute  ownership. 
Divest  Attribute  ownership  and  Release  attribute  ownership. 

5.  Time  Management 

Time  management  services  support  the  synchronization  of  runtime  simulation  data 
exchange.  The  current  HLA  time  management  service  provides  support  for  time-step  and 
event-driven  simulation  systems  but  support  for  platform  level  real-time  simulations  is 
limited  to  wall  clock  time. 
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6. 


Data  Distribution  Management 


Data  distribution  management  supports  the  efficient  routing  of  data  among 
federates  during  the  course  of  a  federation  execution.  This  service  allows  federates  to 
identify  regions  of  interest  and  limit  attribute  to  entities  that  fall  into  those  regions. 

D.  HLA  RULES 

There  are  ten  basic  rules  that  define  the  responsibilities  and  relationships  between 
HLA  federates  and  the  federation.  There  are  ten  rules:  five  rules  apply  to  federations  and 
five  rules  apply  to  federates  [10]. 

1.  Federation  Rules 

•  Rule  1:  Federations  shall  have  an  HLA  FOM,  documented  in  accordance  with  the 

HLAOMT. 

•  Rule  2:  In  a  federation,  all  object  representation  shall  be  in  the  federates,  not  in  the 

runtime  infrastructure.  This  means  that  the  RTI  cannot  be  used  to  track  entity  state.  All 
entity  representations  are  defined  by  the  federate  and  communicated  to  other  federates  via 
the  RTI. 

•  Rule  3:  During  a  federation  execution,  all  exchanges  of  FOM  data  among  federates 

shall  occur  via  the  RTI. 

•  Rule  4:  During  a  federation  execution,  federates  shall  interact  with  the  RTI  in 

accordance  with  the  HLA  IF  Spec.  The  only  way  to  interface  with  the  RTI  is  through  the 
RTI  ambassador  and  the  services  provided  in  that  class 

•  Rule  5:  During  a  federation  execution,  an  attribute  of  an  instance  of  an  object  shall 

be  owned  by  only  one  federate  at  any  given  time.  No  attribute  can  be  published  by  more 
than  one  federate  at  a  time. 


2.  Federate  Rules 

•  Rule  6:  Federates  shall  have  an  HLA  SOM  documented  in  accordance  with  the 

HLA  OMT.  Each  simulation  must  describe  the  functionality  it  will  provide  to  the 
federation.  The  federation  is  not  required  to  use  all  the  functionality  supplied  by  the 
federate. 

•  Rule  7:  Federates  shall  be  able  to  update  and/or  reflect  any  attributes  of  objects  in 

their  SOM  and  send  and/or  receive  SOM  object  interactions  externally,  as  specified  in  their 
SOM. 

•  Rule  8:  Federates  shall  be  able  to  transfer  and/or  accept  ownership  of  attributes 

dynamically  during  a  federation  execution,  as  specified  in  their  SOM. 
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•  Rule  9:  Federates  shall  be  able  to  vary  the  conditions  (e.g.,  thresholds)  under  which 

they  provide  updates  of  attributes  of  objects,  as  specified  in  their  SOM. 

•  Rule  10:  Federates  shall  be  able  to  manage  local  time  in  a  way  that  will  allow  them 

to  coordinate  data  exchange  with  other  members  of  a  federation.  Non-time  managed 
federates  manage  time  internally  in  their  own  way,  but  time  managed  federates  must  manage 
time  in  such  a  way  so  it  appears  there  is  only  one  dock. 


E.  HLA  CONCLUSION 

The  HLA  architecture  is  designed  to  improve  the  method  of  simulation  interaction 
by  making  certain  types  of  simulation  systems  reusable  among  disparate  simulation 
applications.  It  accomplishes  this  goal  by  providing  a  standard  method  of  communicating 
simulation  capabilities  (SOM)  and  a  standard  method  of  defining  how  those  simulations 
will  communicate  on  the  network  (FOM).  The  RTI  provides  the  communications  link  to 
manage  the  operation  of  a  federation  using  the  IF  Spec.  The  HLA  rules  link  it  all  together 
by  providing  guidelines  that  ensure  designers  will  use  all  the  components  is  such  a  way  as 
to  accomplish  the  goal  of  reusable  inter-operating  simulations 
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IV.  IMPLEMENTATION 


A.  INTRODUCTION 

The  goal  is  to  provide  a  dynamic,  flexible,  and  consistent  environment  for  three- 
dimensional  networked  virtual  environments.  Consistency  is  accomplished  by  ensuring  all 
modules  are  available  locally  or  via  the  network  from  a  centralized  location.  As  the 
simulation  executes,  users  decide  which  terrain  module  to  use  and  which  simulation 
entities  will  populate  the  environment.  Bamboo  provides  the  ability  to  dynamically  load 
and  unload  modules.  The  ability  to  add  a  module  provides  dynamic  extensibility.  It  is  the 
ability  to  unload  modules  that  makes  the  system  flexible.  Flexibility  requires  that  the 
implemented  can  change  the  virtual  environment  on  the  fly  without  restarting. 

To  this  end,  the  implementation  has  three  major  components:  the  HLA 
administration  module  (amHLAAdmin),  entity  modules,  and  terrain  modules.  The 
amHLAAdmin  module  manages  the  communication  layer  (RTI),  module  loading  and 
unloading,  and  all  participating  entity  objects.  Each  entity  module  represents  the  behavior 
and  polygonal  representation  for  each  entity.  The  terrain  modules  are  the  same  as  the 
entity  modules  but  they  must  be  identified  as  terrain  for  the  amHLAAdmin  module.  These 
modules  make  up  the  core  of  this  implementation.  Each  component  is  described  in  detail 
in  the  following  sections. 

1.  HLA  Administration  Module  (amHLAAdmin) 

The  amHLAAdmin  module  manages  HLA  RTI  communications,  Bamboo  function 
calls,  the  execution  window,  and  entities  in  the  environment.  All  modules  designed  for  the 
implementation  depend  on  the  amHLAAdmin  module.  Therefore,  Bamboo  ensures  it 
loads  before  any  entity  or  terrain  module.  Similarly,  the  amHLAAdmin  module  depends 
on  various  modules  being  loaded  before  it.  Figure  3  shows  the  module  dependency  tree 
for  a  typical  execution.  Notice  that  amEntity  and  amTerrain  depend  on  amHLAAdmin, 
and  that  amHLAAdmin  depends  on  Visual,  Keyboard,  and  amPageModule. 
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Since  the  amHLAAdmin  module  must  communicate  with  the  RTI  and 
entity/terrain  modules,  the  API  and  pure  virtual  class  provide  the  interface  to  accomplish 
this  communication.  Essentially,  the  amHLAAdmin  module  instantiates  the  Admin  class 
object.  Through  static  functions,  the  Admin  class  provides  the  API  for  entity/terrain 
modules  to  communicate  with  the  RTI  and  manage  instances  of  their  entities.  Each 
entity/terrain  class  must  inherit  from  amObject.  This  object  defines  the  interface  for  the 
Admin  object  to  communicate  with  entity/terrain  modules. 

Figure  4  shows  the  object  model  used  by  this  implementation.  This  figure 
illustrates  the  relationship  between  the  Admin  object  and  the  entity  modules.  It  also  shows 
how  the  pure  virtual  class  amObject  is  used  to  ensure  that  each  federate  transmits  and 
receives  all  information  pertinent  to  the  federation.  An  entity  update  coming  from  the 
network  begins  in  the  RTI  ambassador  receive  buffer. 
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Figure  4:  Object  Interface 


Next,  the  RTI  ambassador  calls  the  AdminFederateAmbassador-:  reflect AttributeValues() 
function  in  the  federate  ambassador).  The  federate  ambassador  is  the  RTI  ambassador’s 
interface  into  the  federate.  This  function  simply  calls  the  Admin  object  function  to  pass 
the  AttributeHandleValuePair  to  the  appropriate  entity. 

Called  by  the  RTI  Ambassador  to  pass 

the  AttributeHandleValuePairSet  tO  3  Specific  entity 

void  AdminFederateAmbassador : : ref lectAttributeValues 

{  RTI: :ObjectID  theObject, 

const  RTI: :AttributeHandleValuePairSet&  theAttributes, 

RTI:  :FederationTime  theTime, 

const  RTI: : User SuppliedTag  theTag, 

RTI : :EventRetractionHandle  theHandle  ) 

throw  (RTI: :ObjectNotKnown, 

RTI :  :  Attributed tKnown, 

RTI : : InvalidFederationTime, 

RTI: : Federatelnternal Error) 

{ 

Admin:  :receiveUpdate(  theObject,  theAttributes,  theTime,  theTag,  theHandle) ; 

)//  end  reflectAttributeValues 

objectiD  is  the  ID  number  for  the  specific  entity 
The  user  SuppliedTag  specifies  the  module  name. 

The  other  parameters  are  not  used  in  this  implementation. 

Figure  5:  Federate  Ambassador  Code  Fragment 
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The  federate  ambassador  calls  the  Admin:  :receiveUpdate()  function  in  the  Admin 
object  (Figure  6).  This  function  locates  the  entity  object,  an  amObject  type,  in  the  object 
list.  If  the  object  exists,  it  is  updated.  If  it  does  not  exist,  the  Admin  object  checks  to  see 
if  the  module  is  loaded.  If  the  module  is  loaded,  then  another  object  representing  that 
entity  is  instantiated.  If  the  module  is  not  loaded,  it  is  loaded  and  an  object  representing 
the  entity  is  instantiated. 


Called  by  the  Federate  Ambassador  to  pass 

the  AttributeHandleValuePairSet  tO  a  Specific  entity 

managed  by  the  Admin  object 


void  Admin: :receiveUpdate(  RTI: : Object ID 

const  RTI:  :AttributeHandleValuePairSet& 

RTI : : Feder ationTime 

const  RTI: : User SuppliedTag 


theObj ect, 
theAt tributes, 
theTime , 
theTag , 


{ 


tmp->receiveUp  dates  ( theObj  ect ,  the  At  tributes,  theTime,  theTag)  ; 
else  {  //  add  module  if  necessary  or  add  simEntity 

if  (Admin:  rmoduleLoaded ( theTag) )  ( _ //  is  module  loaded 


Add  entity  of  module  already  loaded 


cout  «  "adding  new  ■  «  theTag  «  endl; 
Admin :  :  addSimEnt  ity  ( theTag ,  theObj  ect); 
>//  end  if  r 
else  { 


Load  module  and  add  entity  from  module 


cout  «  "Loading  Module  ■  «  theTag  «  endl; 
Admin: : loadModule (theTag) ; 

Admin : : addSimEnt i ty ( theTag ,  theObj  ec  t ) ; 


}  }  } 


Figure  6:  Admin  Object  Code  Fragment 


The  Admin  object  iterates  the  list  of  entities  and  calls  the 
EntityObject::receiveUpdates()  function  of  the  appropriate  entity  (Figure  7).  This 
function  is  defined  in  the  amObject  pure  virtual  class.  This  function  iterates  the 
AttributeHandleValuePair  and  sets  the  appropriate  state  variables  in  the  entity  object. 
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Called  by  the  Admin  object  to  pass 

the  AttributeHandleValuePairSet  tO  the  entity 

void  Boid:  rreceiveUpdates  (  RTI : : Ob j ec tID  oid, 

const  RTI : :AttributeHandleValuePairSet&  theAttributes, 

RTI : : FederationTime  theTime,  RTI: :UserSuppliedTag  theTag) 

{ 

RTI : ; AttributeHandle  attrHandle; 
unsigned  long  valueLength; 

Iterate  theAttributes  and  set  the  values  in  the  entity  object 

for  {  unsigned  int  i  =  0;  i  <  theAttributes .size( ) ;  i++  )  ( 
attrHandle  =  theAttributes .getHandle (  i  }; 
if  (  attrHandle  ==  Admin: igetPos it ionAttrHandle ( )  ){ 
npsVec3f  tmp; 

theAttributes .getValuet  i,  (char*)&tmp,  valueLength  ); 
setPosition(tmp) ; 

}//end  if 

else  if  (  attrHandle  ==  Admin: :getOrientat ionAttrHandle ( )  )  [ 
npsQuatemion  tmp; 

theAttributes .getValue(  i,  (char*) &tmp,  valueLength  >; 
setOrientation(tnp) ; 

}//  end  else  if 

else  if  (  attrHandle  *=  Admin:  :getVe loci tyAttrHandle  ()  )  { 
npsVec3f  tmp; 

theAttributes.getValuef  i,  (char*) &tmp,  valueLength  ); 
setVelocity {tmp) ; 

)  )  ) 


Figure  7:  Entity  Object  Code  Fragment 

The  Admin  object  is  the  portion  of  the  amHLAAdmin  module  that  implements  the 
Admin  API.  This  API  is  fully  described  in  Appendix  A:  Implementation  Tutorial.  Users 
apply  the  Admin  API  to  ensure  their  modules  are  managed  as  part  of  the  HLA  federation 
and  the  entities  they  represent  are  properly  registered  and  updated  by  the  RTI.  Proper  use 
of  the  API  insures  that  the  federation  will  comply  with  HLA  Rules. 

The  amHLAAdmin  module  loads  and  unloads  modules  in  two  ways:  either 
automatically  at  the  request  of  the  system  or  explicitly  at  the  request  of  the  user.  The 
Admin  class  defines  certain  API  functions  that  load  and  unload  modules  at  the  request  of  a 
module  or  the  system.  Finally,  the  amHLAAdmin  module  loads  user  requested  modules 
using  a  separate  module  called  the  amPageModule  on  which  it  depends.  This  module 
loads  automatically  when  the  amHLAAdmin  module  loads.  The  amPageModule  executes 
the  Bamboo  calls  that  load  and  unload  user  requested  modules.  It  installs  two  keyboard 
events  that  the  implementer  uses  to  arbitrarily  load  and  unload  modules. 

The  amHLAAdmin  module  manages  all  of  the  simulation  entities.  Functionality 
related  to  this  task  are  the  HLA  object  management  tasks  like  registering  and  deleting 
objects  and  ensuring  state  updates  transmit  to  the  correct  entity.  The  amObject  class,  that 
all  objects  inherit  from,  allows  the  amHLAAdmin  module  to  iterate  its  list  of  simulation 
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entities  and  update  each  object  based  on  its  ObjectED,  an  identification  number  provided 
by  the  RTI. 

Each  module’s  capability  means  nothing  unless  the  executable  is  extended  to 
include  the  new  module.  Figure  8  illustrates  the  execution  tree  used  in  this 
implementation.  The  amHLAAdmin  module  created  the  symbols  in  bold  outline  when  the 
module  loaded.  A1  is  a  callback  attached  to  the  main  callback  handler  created  by  the 
Bamboo  core.  A1  “ticks”  the  RTI  to  provide  CPU  time  to  the  RTI  ambassador  and  the 
federate  ambassador.  This  callback  drives  the  federate  by  processing  all  updates  and 
providing  them  to  the  correct  simulation  entity.  A2  is  a  callback  attached  to  the  draw 
callback  handler  of  the  Visual  module.  This  callback  calls  the  display  function  of  all 
simulation  objects  using  a  call  to  a  virtual  function  defined  in  amObject  that  all  simulation 
entities  must  implement.  Finally  AK  is  the  callback  representing  all  keyboard  events  that 
are  processed  by  the  amHLAAdmin  module. 


Figure  8:  Execution  Callback  Tree 
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2. 


Simulation  Entities  (amEntity/amTerrain) 


As  the  VE  executes,  if  an  entity  is  updated  that  is  not  currently  represented  on  the 
local  machine,  the  RTI  initiates  the  discovery  process.  The  UserSuppliedTag,  a  character 
string  that  is  transmitted  with  each  update  handle  value  pair,  represents  the  module  name. 
The  handle  value  pair  is  the  HLA  method  of  creating  a  byte  array  for  transmission  on  the 
network.  If  this  module  is  already  loaded,  then  another  object  from  this  module  is 
instantiated.  If  the  module  does  not  exist,  then  Bamboo  loads  it  and  instantiates  an  object 
that  represents  the  newly  discovered  entity. 

Each  simulation  entity  is  a  Bamboo  module.  Each  module  has  two  major 
components:  the  object’s  polygonal  representation  and  its  general  behavior.  Therefore, 
when  a  module  loads  as  a  result  of  a  remote  object  update,  the  user  collects  all  the 
controls  of  that  module.  Then  Bamboo  plugs  the  module  into  the  local  event  loop  so  local 
processing  can  compute  entity  appearance  and  behavior.  Figure  4  shows  the  entity 
module  loaded  and  inserted  in  the  executable  with  two  sets  of  callbacks.  B1  is  the  preapp 
callback  that  gives  the  user  the  ability  to  control  the  object  with  keyboard  input.  BK  is  the 
callback  for  all  the  keyboard  inputs  defined  by  the  module. 

Because  this  system  passes  behaviors  along  with  polygonal  representation,  there  is 
an  opportunity  to  reduce  network  traffic  by  reducing  the  details  of  entity  behavior  that 
previous  systems  transmitted  via  the  network.  This  occurs  because  each  entity  computes 
its  behavior  locally  not  from  a  remote  location.  For  instance,  each  entity  provides  collision 
event  behavior  locally  without  the  need  for  multiple  interactions  transmitted  across  the 
network.  Now  the  entity  module  notifies  the  federation  only  that  a  collision  occurred,  not 
resulting  detailed  state  changes.  Each  entity  computes  those  state  changes  locally  as  a 
result  of  the  interaction.  The  result  is  a  series  of  simulation  actors  whose  behaviors  and 
polygonal  representations  load  dynamically  at  runtime.  This  allows  simulation  managers 
to  easily  experiment  with  the  content  of  the  environment  by  adding  and  subtracting 
functionality  at  runtime.  The  tendency  is  to  think  that  this  applies  only  to  the  graphically 
represented  entities  but  it  could  mean  that  data  loggers  or  analysis  modules  dynamically 
load  and  unload  to  collect  and  analyze  simulation  data.  Bamboo  provides  an 
unprecedented  method  of  adding  functionality  to  an  executing  networked  virtual 
environment. 


3.  Graphics  Rendering 

Bamboo’s  Visual  module  renders  the  graphical  objects  in  the  scene.  The 
amHLAAdmin  module  and  the  entity  modules  update  the  object's  position  and  orientation. 
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Each  entity  module  registers  callbacks  with  the  Visual  module  to  ensure  accurate 
rendering  of  the  simulation  entity.  These  callbacks  call  the  appropriate  functions  when  the 
system  needs  to  render  the  graphical  representation  of  each  entity.  See  Figure  4  for  the 
callback  tree  representing  this  implementation. 

B.  FEDERATION  OBJECT  MODEL/SIMULATTON  OBJECT  MODEL 

This  implementation  has  a  simple  FOM.  Table  4  displays  the  FOM  tables  for  the 
implementation.  The  FOM  and  SOM  are  the  same  for  this  implementation  because  each 
federate  is  based  on  the  amHLAAdmin  Module  common  for  all  federates.  The  FOM 
defines  the  Entity  State  Object  and  its  attributes  that  define  the  state  of  the  object.  The 
Entity  State  Object  defines  the  attributes  that  will  be  communicated  to  the  network.  Do 
not  confuse  this  object  with  the  software  objects  defined  in  the  implementation.  Those 
C++  objects  may  define  more  variables  that  define  their  state  but  are  not  communicated  to 
the  network.  The  FOM  also  defines  a  very  simple  interaction  called  Collision.  Its  only 
parameter  is  the  ObjectID  number  assigned  to  the  entity  that  has  been  collided  with.  The 
purpose  of  this  interaction  is  to  communicate  to  the  federation  the  ObjectID  of  the  entity 
that  was  damaged.  Each  federate  then  updates  the  state  of  that  entity. 


;  Object  Cla**  Structure  Table  ; 

^Entity  State  (PS) 


Object  Interaction  Table 

Interaction 

Structure 

Initiating  Object 

Receiving  Object 

Affected 
Iciass  !  Attributes 

|  Affected 
^  Class  Attributes 

Interaction 

Parameters 

Init 

Sense  ; 
React 

[Collision 

iEntityState'None 

jEntityState?  Damage 

Entity  ID 

IR  i 

Object/Into  radio 
n 

Attribute  ; 
Parameter  [Date  type 

Card¬ 
inal  it 

Unit* 

Reso¬ 

lution 

Accuracy 

Update 

Condition 

Tranteerabl 

• 

Acceptable 

Updateabl 

• 

Reflect*  bl 

• 

ErtityState 

Position  [any 

1 

perfect 

always 

Periodic 

TA  IUR 

Orientation  [any 

1 

perfect 

always 

Periodic 

TA 

UR 

Velocity  [any 
^Ammunition!  any 

1 

1 

. 

perfect 

always 

Periodic 

TA 

UR 

Damage  [any 

1 

perfect 

always 

Periode 

. j 

TA 

UR 

[Collision 

fuhsigned 
EntitylD  [long 

1 

perfect 

always 

N/A 

N/A 

N/A 

N/A 

Table  4:  Implementation  FOM  Tables 
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C.  IMPLEMENTATION  CONCLUSION 


Recall  the  goal  is  a  dynamically  extensible,  flexible,  consistent,  and  specific  NVE. 
Dynamic  extensibility  is  accomplished  by  using  Bamboo  to  load  and  unload  modules.  The 
NVE  is  consistent  because  the  amHLAAdmin  module  ensures  all  entity  and  terrain 
modules  required  by  the  designers  be  loaded  when  required.  Each  module  is  specific 
because  the  programmer  is  only  concerned  with  one  module  representing  a  particular 
entity.  That  programmer  no  longer  has  to  concern  himself  with  the  representations  and 
behaviors  of  the  other  entities  in  the  environment.  Finally,  all  of  this  adds  up  to  flexible 
environment  that  can  be  changed  during  runtime  to  the  state  required  by  the  simulation 
managers. 

The  preceding  sections  provide  the  overview  of  how  the  implementation 
accomplishes  the  goal  of  providing  a  dynamically  extensible,  flexible,  specific  and 
consistent  NVE.  Appendix  A  provides  a  detailed  implementation  tutorial  that  guides  a 
user  through  the  details  required  to  implement  an  amEntity  module.  Appendix  B  provides 
the  code  examples  that  accompany  the  implementation  tutorial.  Together  these  two 
documents  walk  a  user  through  the  correct  use  of  the  HLA  RTI,  Bamboo  and  the 
amHLAAdmin  module. 
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V.  RESULTS  AND  LIMITATIONS 


A.  PERFORMANCE  RESULTS 

Two  measures  of  performance  were  used  to  judge  the  merits  of  this 
implementation:  frame  rate  per  second  and  average  time  to  clear  the  event  buffer.  Frame 
rate  per  second  describes  how  the  implementation  impacts  the  graphics  subsystem.  Falling 
below  ten  frames  per  second  severely  hampers  virtual  environment  realism.  Time  to  clear 
buffers  shows  the  impact  of  increasing  numbers  of  entities  on  the  system’s  ability  to 
update  each  one.  Each  measure  was  sampled  with  different  communication  reliability 
parameters,  specific  numbers  of  entities,  and  federates  participating  in  the  environment. 

1.  Test  Description 

The  system  used  to  evaluate  the  implementation  is  a  Windows  NT  4.0  LAN,  with  a 
166  MHz  Pentium  MMX  CPU  and  32  Megabytes  of  RAM.  Each  system  connects  to  the 
100  Mbps  LAN  with  a  3Com  10/100  Mbps  network  interface  card  through  a  100  Mbps 
hub.  The  graphics  subsystem  on  these  systems  is  not  accelerated.  All  graphics  are 
computed  on  the  system  processor.  There  was  a  single  federate  per  system.  Each 
federate  computed  and  transmitted  position,  orientation,  and  velocity  data  every  fifth 
frame. 


Figure  9:  HLA  Message  Transport  Types 
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There  are  two.  communication  reliability  settings  defined  by  the  HLA  IF  Spec: 
FED_RELIABLE  and  RED_BEST_EFFORT.  FED_RELIABLE  uses  the  federation 
execution  to  ensure  that  each  message  of  this  type  is  delivered  to  each  federate  in  the 
federation.  This  adds  a  significant  number  of  messages  to  the  network  since 
acknowledgements  are  required  to  confirm  delivery  of  each  message. 
FED_BEST_EFFORT  reduces  message  traffic  compared  to  FED_RELIABLE  because 
each  federate  transmits  its  messages  to  a  multicast  address  where  every  other  federate 
reads  the  messages.  There  is  no  requirement  for  acknowledgements,  but  there  is  a  small 
chance  that  a  message  may  be  delivered  improperly  or  not  at  all.  Figure  9shows 
graphically  the  differences  between  FED_RELIABLE  and  FED_BEST_EFFORT 
reliability  settings.  FED_RELIABLE  transport  creates  a  bottleneck  because  the  federation 
execution  process  acts  as  a  server  ensuring  that  all  federates  receive  each  update.  The 
FED_RELIABLE  transport  type  only  allowed  two  federates  in  the  federation  before  the 
federation  execution  was  bottlenecked,  so  no  further  measurements  were  taken.  Two 
federates  does  not  make  a  very  interesting  virtual  world. 

2.  Frame  Rate  Results 

Figure  10  shows  the  frame  rate  results  for  a  federate  using  the 
FED_BEST_EFFORT  transport  protocol.  Notice  that  the  frame  falls  as  the  number  of 
entities  in  the  federation  increases.  This  is  to  be  expected.  Each  new  federate  brings  44 
more  polygons  to  the  virtual  world. 
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Figure  10:  Performance  Results 


3.  RTI  Event  Buffer  Read  Results 

Figure  10  shows  the  time  to  clear  buffer  results.  The  time  to  clear  buffer  is  the 
time  required  to  process  all  events  in  the  RTI  event  queue.  In  this  implementation  all 
events  are  attribute  updates.  This  test  shows  the  average  time  it  took  to  clear  the  event 
buffer.  Recall  that  the  reliable  transport  type  was  only  able  to  accommodate  two  federates 
with  a  total  of  22  entities  in  the  federation,  while  the  best  effort  transport  type 
accommodated  more  than  three  times  that  with  7  federates  and  77  entities.  Notice  that  the 
average  time  to  clear  the  buffer  increases  with  the  number  of  entities  in  the  federation. 
This  could  limit  scalability,  but  recall  the  limited  power  of  the  test  systems  and  that  the 
entity  module  in  the  test  does  not  implement  dead  reckoning.  Dead  reckoning  could 
reduce  the  number  of  entity  updates  thus  improving  the  time  to  clear  the  buffer. 

B.  LIMITATIONS 

There  are  two  major  limitations  in  this  implementation.  The  RTI  limits  the 
implementation  due  to  its  static  nature.  The  design  of  the  amHLAAdmin  module  is 
limited  because  it  lacks  a  method  of  extending  the  executable  by  providing  a  separate 
thread  to  handle  entity  updates. 
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1. 


HLA/RTI  Generalization 


This  implementation  is  generalized  except  for  the  HLA/RTI  functionality.  The 
RTI  limits  the  functionality  in  two  ways.  First,  the  RTFs  use  of  text  files  and  environment 
variables  limit  the  flexibility  of  this  implementation.  An  API  interface  that  set  the  RTFs 
state  would  significantly  increase  the  flexibility  of  the  system.  Implementation  of  the  HLA 
functionality  requires  that  RTI  be  installed  on  every  machine  it  is  used  on.  It  would  be 
much  more  flexible  if  the  RTI  could  be  instantiated  anytime  and  its  state  set  with  API 
function  calls.  This  would  allow  the  RTI  to  be  part  of  the  amHLAAdmin  module  and 
could  be  loaded  in  one  step  without  having  to  actually  install  the  RTI  so  that  the  static  text 
files  and  environment  variables  are  defined.  Second,  the  FOM  is  predefined  and  parsed  by 
the  RTI  at  runtime.  If  there  was  an  API  interface  to  change  the  FOM  during  runtime,  the 
federation  could  extend  its  capability  without  requiring  that  the  federation  execution  be 
restarted. 


2.  HLA  Memory  Footprint 

Each  federation  has  three  processes  that  must  exist  in  order  for  the  federation  to 
operate:  the  RTI  executive  process,  the  federation  executive,  and  at  least  one  federate. 
The  RTI  executive  process  requires  approximately  2.5  MB  of  RAM  in  order  to  run,  while 
the  federation  executive  requires  2.5  MB.  Each  federate’s  memory  requirements  will 
vary,  but  the  local  RTI  component,  or  RTI  ambassador  requires  12  MB.  This  is  a  total  of 
17  MB  required  on  one  system.  This  is  a  significant  amount  of  memory  that  must  be 
considered  when  designing  systems  portable  to  desktop  systems. 

3.  amHLAAdmin  Module  Limitations 

The  amHLAAdmin  module  does  not  provide  a  method  for  extending  the 
executable.  If  this  module  provided  a  set  of  callbacks  similar  to  the  visual  module’s  app, 
cull,  draw  system,  the  implementation  could  better  control  the  sending  and  receiving  of 
information  through  the  RTI.  For  example,  a  separate  thread  could  be  started  that 
continuously  “ticks”  the  RTI,  thus  keeping  its  receive  buffers  clear.  Additionally,  a 
generalized  system  that  allows  each  module  to  register  callbacks  on  an  update  loop  would 
provide  a  more  efficient  method  of  updating  entity  state.  These  improvements  were  not 
made  because  the  significance  of  the  processing  time  required  to  update  entity  state  was 
not  discovered  until  the  final  performance  tests  were  run.  Future  improvements  to  the 
system  will  require  a  better  method  of  managing  processor  time  for  the  RTI  to  update 
entity  state. 
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VI.  CONCLUSIONS 


A.  CONCLUSION 

The  implementation  meets  the  requirements  set  out  in  the  introduction  concerning 
the  improvements  NVEs  require.  The  requirements  are  the  virtual  environment  must  be 
dynamically  extensible,  flexible,  specific,  and  consistent.  This  implementation  is 
dynamically  extensible.  Bamboo  does  an  excellent  job  of  providing  this  capability  by 
implementing  the  ability  to  dynamically  extend  the  executable  and  providing  a  system  that 
defines  module  dependency.  The  ability  to  load  and  unload  modules  on  the  command  of 
the  user  or  the  system  at  any  time  during  execution  adds  flexibility  to  the  NVE.  This 
means  simulation  designers  can  rapidly  prototype  simulation  executions  in  real  time  and 
effectively  design  and  implement  the  virtual  environment.  This  demonstration  verifies  that 
simulation  designers  can  be  more  specific.  In  other  words,  programmers  just  need  to 
implement  their  module.  They  no  longer  need  to  represent  the  other  entities  that  will  exist 
in  the  NVE  or  approximate  their  behavior.  An  entity  module  that  can  be  loaded  as  the 
situation  changes  and  unloaded  when  no  longer  needed  represents  these  remote  entities. 
Finally,  this  system  ensures  that  all  simulations  operating  in  the  NVE  are  consistent  with 
each  other.  The  problem  of  different  terrain  models  at  each  simulation  site  is  solved 
because  all  sites  receive  the  terrain  module  from  the  same  location  and  execute  it  in  the 
same  manner.  This  same  logic  applies  to  the  entity  modules. 

B.  FUTURE  WORK 

The  following  lists  future  projects  that  could  improve  real  time  virtual 
environments. 


1.  Network  Bandwidth  and  Latency  of  the  RTL 

It  is  very  difficult  to  quantify  the  effects  the  RTI  has  on  the  network.  We  do  not 
know  the  methods  used  to  keep  the  distributed  local  RTI  components  updated.  What  is 
the  time  management  method  employed  by  the  RTI?  How  are  the  receive  buffers  filled 
and  emptied?  What  is  the  most  efficient  method  of  clearing  the  buffers?  The  results 
indicate  that  more  information  is  required  to  increase  the  numbers  of  entities  modeled  in  a 
real  time  virtual  environment. 
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2.  Methods  for  Reducing  Network  Traffic  Required  to  Maintain 
Consistent  Entity  State. 

This  work  refers  to  ways  to  improve  the  RTI  for  real-time  simulations.  Area  of 
interest  management  is  a  method  of  accomplishing  this  goal.  The  new  version  of  the  RTI, 
version  1.3-3,  has  implemented  its  own  area  of  interest  management  system  call  Data 
Distribution  Management  (DDM).  Future  work  could  entail  implementing  support  for 
DDM  into  this  implementation. 


3.  Improvements  to  the  Current  Implementation 

There  are  several  ways  to  improve  this  implementation.  First,  the  amHLAAdmin 
module  could  implement  a  series  of  callback  handlers  that  accomplish  the  entity  updates 
and  interactions  required  by  the  system  This  improvement  would  make  the 
implementation  more  general  by  removing  the  requirement  for  the  amObject  pure  virtual 
class  interface.  Next,  multi-thread  the  implementation  to  provide  specific  amounts  of 
processing  time  to  the  RTI  and  visual  module.  Finally,  implement  a  system  that  ensures 
that  locally  computed  objects  are  updated  first.  Currently,  all  entities  are  in  the  same  list. 
Locally  computed  objects  should  have  a  separate  list  so  they  may  be  updated  at  a  greater 
rate. 
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APPENDIX  A:  IMPLEMENTATION  TUTORIAL 


A.  INTRODUCTION 

This  tutorial  describes  how  to  implement  a  module  that  will  operate  using  the 
HLAAdmin  implementation.  It  has  three  sections:  Bamboo  module  implementation,  HLA 
Implementation,  and  Demo.  The  Bamboo  module  implementation  section  describes  how 
to  build  a  module  for  use  with  the  Bamboo  virtual  environment  toolkit.  The  HLA 
implementation  section  outlines  the  HLA  concepts  that  the  user  must  understand  to 
implement  a  module  for  the  HLAAdmin  implementation.  Finally,  the  Demo  section 
describes  how  to  run  the  existing  implementation.  Taking  each  section  in  turn  will  ensure 
the  user  of  an  overall  understanding  of  the  HLAAdmin  implementation. 

The  system  requirements  for  this  implementation  are,  Windows  NT  4.0,  Visual 
C++  5.0,  RTI  1.0-3  and  rktools.  Visual  C++  is  the  compiler  used  in  the  examples  and 
rktools  provides  the  functionality  needed  to  use  makefiles  that  are  very  similar  to  UNIX 
makefiles.  All  the  RTI  functionality  described  in  this  tutorial  is  explained  in  detail  in  the 
RTI  Programmers  Guide,  see  the  bibliography  in  the  main  section  of  the  thesis. 

B.  BAMBOO  MODULE  IMPLEMENTATION 

The  easiest  way  to  grasp  how  to  implement  a  Bamboo  module  is  to  use  one  as  an 
example.  I  will  use  the  amBoid  module,  available  in  the  code  appendix,  as  the  example 
module.  Bamboo  modules  are  made  up  of  a  minimum  of  four  files:  module.h,  module.c, 
amBoid.h,  amBoid.c.  (The  amBoid  files  are  examples;  any  name  can  be  there.)  Each 
module  is  identified  to  the  Bamboo  kernel  by  six  global  functions  defined  in  the  module.c 
file:  getModuleName(),  getModuleVersion(),  getModuleDate(),  getModuleText(), 
initModule()  and  exitModule().  As  a  module  is  loaded,  Bamboo  creates  a  bbModule 
object  that  holds  pointers  to  these  functions. 

When  the  module  is  loaded,  the  bbModule  object  executes  the  initModule() 
function.  The  initModule()  function  does  the  work  required  to  add  the  module  to  the 
executable  and  instantiate  any  object  required  by  the  module.  The  exitModule()  function 
removes  the  structures  used  to  integrate  the  module  into  the  executable  and  deallocates 


33 


the  memory  associated  with  any  objects  created  for  use  by  the  module  being  deleted. 
Notice  in  the  example  module.c  that  the  definition  for  the  initModule()  function  makes  one 
call  to  the  initamBoid()  function  in  amBoid.c,  and  the  exitModule  function  makes  one  call 
to  the  exitamBoid()  function  in  amBoid.c. 

The  initamBoid()  function  does  the  functions  described  above.  This  function  is  run 
only  once  immediatley  after  the  module  is  loaded  into  memory.  First,  it  instantiates  a  Boid 
object  for  use  by  the  module.  Then  it  calls  the  initKeyboardFunc()  to  add  callbacks  for 
keyboard  events.  This  is  one  way  to  add  the  module  into  the  program  execution.  The 
other  method  is  to  add  callbacks  that  will  include  the  module’s  functionality  into  the 
executable.  This  module  is  added  to  the  executable  by  adding  callbacks  to  the  Visual 
module.  The  initVisualModule()  function  adds  a  callback  to  the  preapp  callback  handler. 
The  callback  is  associated  with  the  preAppFunc()  defined  in  amBoid.c.  This  function 
defines  the  keyboard  controls  and  behavior  for  the  Boid  object  created  in  the  loadBoid() 
function.  After  this  function  is  executed,  the  module  executes  as  part  of  the  Bamboo.exe 
executable  until  a  command  to  unload  the  module. 

On  the  command  to  unload  a  module,  the  bbModule  object  calls  the  exitModule() 
function  defined  in  the  module.c  file.  This  function  in  turn  calls  the  exitamBoid()  function. 
The  exitamBoidO  does  the  housekeeping  required  to  remove  from  memory  all  structures 
like  callbacks  or  objects  related  to  the  module.  In  this  case,  the  exitamBoid()  function  first 
removes  the  event  responses  from  the  keyboard.  Notice  that  these  commands  are  in  the 
reverse  order  of  the  commands  that  were  used  to  create  the  keyboard  events.  Next  the 
preapp  callback  is  removed.  Finally,  all  objects  associated  with  this  module  are  deleted 
from  memory. 

The  last  Bamboo  feature  that  will  be  discussed  deals  with  module  dependency. 
Bamboo  extends  the  plug-in  metaphor  by  implementing  a  system  that  allows  modules  to 
depend  on  other  modules  for  execution.  In  this  example,  the  amBoid  module  depends  on 
the  npsVisualModule,  the  bbKeyboardModule  and  the  amHLAAdmin  module.  The 
module.txt  file  defines  these  dependencies.  Bamboo  ensures  that  all  dependent  modules 
are  loaded  first  before  the  module  that  needs  them  is  loaded. 
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This  concludes  the  Bamboo  section.  It  is  not  complicated  to  load  and  unload  a 
Bamboo  module.  The  user  is  required  only  to  define  the  six  functions  in  the  module.c  file. 
Understand  that  Bamboo’s  greatest  strength  is  its  convention  that  defines  generalized 
methods  to  load  and  unload  modules  while  providing  a  system  that  ensures  module 
dependencies  are  enforced. 

C.  HLA  IMPLEMENTATION  SECTION 

HLA  is  implemented  mainly  in  the  amHLAAdmin  module.  Entity  modules  just 
make  an  Admin  API  call  to  pass  or  receive  information  to  the  RTI.  There  is  one  exception 
to  this  that  I  will  address  later  in  this  section.  The  Admin  API  wraps  ups  all  RTI 
ambassador  functions.  When  the  amHLAAdmin  module  loads,  it  instantiates  a  single 
object  of  type  Admin.  The  entire  API  is  static  functions  defined  in  the  Admin  class. 

The  Admin  class  uses  the  following  RTI  functionality  (*  is  a  Federate  Ambassador 
function): 

Federation  Management 

CreateFederationExecution 
JoinFederationExecution 
ResignFederationExecution 
DestroyFederationExecution 
Declaration  Management 
PublishObjectclass 
PublishlnteractionClass 
SubscribeObjectClassAttributes 
SubscribelnteractionClass 
Object  Management 
RequestID 
RegisterObject 
UpdateAttributeValues 
DiscoverObject* 

ReflectAttributeValues* 

Sendlnteraction 

Receivelnteraction* 

DeleteObject 

RemoveObject* 

RTI  Services 
Tick 
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The  RTI  has  other  functions  that  do  not  apply  to  this  implementation  like  time 
management  and  ownership  management.  If  this  functionality  is  required,  the  Admin 
object  can  be  extended.  Refer  to  the  Admin.c  file  in  the  code  appendix  for  the  following 
functions.  Notice  the  Admin  class  constructor  is  protected.  There  can  be  only  one 
instance  of  the  Admin  class  active  so  a  singleton  is  implemented  called  getlnstance()  that 
creates  the  object  the  first  time  it  is  called  and  returns  the  pointer  to  the  object  every  time 
it  is  called.  The  Admin  constructor  instantiates  the  RTI  ambassador  (rtiAmb)  and  the 
Federate  ambassador  (fedAmb)  objects.  The  rtiAmb  is  the  predefined  object  that  contains 
all  the  functionality  that  implements  the  IF  Spec.  The  fedAmb  is  a  pure  virtual  class  that 
defines  the  interface  between  the  RTI  and  the  implementation.  Each  rtiAmb  call  results  in 
a  return  value  from  the  RTI  or,  in  the  case  of  updates,  a  call  to  a  fedAmb  function.  Let  us 
discuss  how  the  implementation  uses  each  of  the  above  RTI  services  and  discuss  the  code 
that  implements  the  service. 

1.  Federation  Management 

The  Admin  constructor  shown  in  Admin.c.  makes  calls  to 
Admin:  :createFederationExecution()  and  Admin:  :joinFederation().  The 
createFederationExecution()  function  calls  Admin:  :rtiAmb- 

>createFederationExecution(fedExecName)  and  passes  it  a  char*  that  defines  the  name  of 
the  Federation  execution.  If  the  federation  already  exists,  the  rtiAmb  throws  a  federation 
already  exists  exception.  If  the  federation  is  new,  then  a  fedex  process  is  spawned  by  the 
RTI.  The  Admin:  :rtiAmb->joinFederationExecution(federateName,  fedExecName, 
fedAmb)  passes  it  the  name  of  the  federate,  the  federation  execution  name  and  a  reference 
to  the  fedAmb  object.  The  name  of  the  federate  is  name  mangled  by  the  RTI  so  it  does 
not  have  to  be  unique  and  the  fedExecName  must  be  the  same  as  was  used  in  the 
createFederationExecution()  function.  The  fedAmb  reference  is  a  pointer  to  the  fedAmb 
created  in  the  Admin  constructor.  The  loop  is  used  to  give  to  the  federate  multiple  tries  to 
join  the  federation  because  the  federation  execution  may  require  more  time  to  configure 
itself  before  it  is  able  to  return  the  federate  ID.  The  federatelD  is  a  unique  number 
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assigned  by  the  fedex  that  identifies  your  federate.  It  is  not  required  anywhere  but  may  be 
required  by  the  user. 

The  Admin:  :resignFederate()  function  handles  the  resign  federate  and  destroy 
federate  management  functions.  This  function  first  calls  Admin:  :rtiAmb- 
>resignFederation()  and  passes  an  enumeration  that  defines  the  clean  up  the  user  wants 
done  prior  to  federate  resignation.  The  implementation  uses 
DELETE J3BJECTS_AND_RELEASE_ATTRIBUTES.  This  value  results  in 
removeObject()  calls  to  the  fedAmb  for  all  locally  updated  entities  and  releases  the 
attributes  on  any  objects  that  must  transfer  attribute  ownership  because  the  federate  is 
resigning.  The  final  call  in  this  function  is  to  the  Admin: :rtiAmb->destroyFederation(). 
This  function  destroys  the  federation  if  there  are  no  other  federates  operating,  otherwise 
an  exception  is  thrown  and  the  federation  continues. 

2.  Declaration  Management 

Declaration  Management  identifies  to  the  rtiAmb  all  the  objects/interactions  and 
attributes/parameters  that  the  federate  is  interested  in.  After  the  federate  is  joined,  the 
user  must  get  from  the  rtiAmb  the  enumerated  values  for  the  objects/interactions  and 
attributes/parameters  computed  when  the  FOM  was  parsed.  The  Admin:  :Init()  function 
uses  RTI  support  functions  that  use  the  information  from  the  FOM  to  provide  these 
enumerated  values  for  the  different  objects/interactions  and  attributes/parameters.  Notice 
the  Init()  function  uses  specific  functions  that  provide  the  enumerated  values  for  the 
different  Objects  (getObjectClassHandlefchar  *))  and  Attributes 

(getAttributeHandle(ObjectTypeEnumchar  *))  that  will  be  used  by  the  federate.  The  char 
*  parameter  must  match  exactly  with  the  strings  used  to  describe  the  Objects  and 
Attributes  in  the  FOM. 

After  the  enumerated  values  are  saved  by  the  user  using  the  Init()  function,  the 
user  calls  the  Admin:  :PublishAndSubscribe()  function.  This  function  makes  RTI  calls  that 
tell  the  rtiAmb  which  Objects/Interactions  and  Attributes/Parameters  the  federate  will 
publish  and  subscribe.  The  mechanics  of  this  operation  begin  with  the  user  building  an 
RTI::AtrributeHandleSet.  This  data  structure  holds  the  attribute  enumerations  for  a 
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specific  object.  The  first  part  of  the  PublishAndSubscribe()  function  builds  the 
RTI::AtrributeHandleSet.  First  the  set  is  declared.  Then  space  is  allocated  for  five 
attributes  using  the  create  method  of  the  RTI::HandleSetFactory  object.  Finally,  all 
attributes  that  the  federate  wants  are  added  to  the  set  using  the  add(AttributeHandle) 
method  and  passed  the  enumeration  for  the  specific  attribute  to  be  added.  After  all  the 
attributes  are  added  to  the  HandleSet  the  Admin:  :ms_rtiAmb- 
>subscribeObjectClassAttribute(  ClassHandle,  *HandleSetFactory )  and 
Admin:  :ms_rtiAmb->publishObjectClass(ClassHandle,  *HandleSetFactory)  are  called  to 
tell  the  rtiAmb  those  objects  that  will  be  published  and  subscribed.  The  last  functions  are 
for  subscribing  and  publishing  Interactions.  Notice  that  these  functions  do  not  require  a 
HandleSetFactory.  When  a  federate  subscribes  or  publishes  an  interaction,  it  accepts 
responsibility  for  all  the  parameters  of  that  interaction,  hence  there  is  no  need  to  tell  the 
rtiAmb  which  parameters  it  is  responsible  for. 

The  above  functions  accomplish  all  the  tasks  required  to  publish  and  subscribe  to 
objects/interactions  and  attributes/parameters.  These  are  required  tasks  that  all  federates 
must  accomplish  in  order  to  participate  in  the  federation. 

3.  Object  Management 

Object  management  services  provide  the  functionality  to  identify  entities  to  the 
RTI,  discover  them  on  remote  federates,  and  update  their  attributes  during  the  federation 
execution.  The  RTI  requires  that  all  entities  are  associated  with  an  Object  defined  in  the 
FOM.  All  entities  must  possess  a  unique  ID  number  provided  by  the  RTI.  This  number 
identifies  the  entity  on  all  federates  in  the  federation  and  ensures  updates  and  interactions 
are  processed  on  the  correct  entity. 

The  first  task  when  adding  an  entity  to  the  federation  is  getting  its  Objectld  from 
the  rtiAmb  then  registering  that  ID  with  the  rtiAmb.  The  Admin:  :registerObject()  function 
accomplishes  these  tasks.  First  the  Admin: :ms_rtiAmb->requestID(RTI::ObjectIDCount, 
RTI:: Objectld,  RTI::ObjectId )  function  provides  the  ObjectlD  numbers.  Then  the 
Admin::ms_rtiAmb->registerObject(  RTI::ClassHandle,  RTI::ObjectId )  function  registers 
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the  entity  with  the  rtiAmb  and  associates  it  with  a  Object  that  was  previously  published  or 
subcribed. 

After  the  object  is  registered  with  the  rtiAmb,  the  entity  will  be  updated  and  its 
attributes  reflected  on  all  participating  federates.  This  task  requires  that  the  entity  be 
discovered  by  each  federate  in  the  federation.  Discovery  requires  that  the  entity  be 
updated  at  least  once.  On  the  first  update,  the  rtiAmb  calls  the 

FederateAmbassador::discoverObject()  function.  This  function  then  ensures  the  module  is 
loaded  that  represents  this  object.  After  the  module  is  loaded  an  entity  is  instanced  and  its 
state  is  updated  with  the  attributes  passed  by  the  rtiAmb.  Refer  to  the 
AdminFederateAmbassador.c  file  for  the  discoverObject()  function.  After  the  object  is 
discovered,  all  updates  come  to  it  through  the 

FederateAmbassador::reflectAttributeValues()  function.  We  will  look  at  how  the 
attributes  are  updated  first.  Then  we  will  look  at  the  discoverObject()  function  is  detail. 

Entities  are  updated  using  the  rtiAmb->updateAttributeValues()  function.  The 
implementation  calls  this  function  in  the  Admin:  :sendEntityUpdate(RTI::ObjectID  , 
RTI::AttributeHandleValuePairSet&  ,  const  RTI::UserSuppliedTag  ).  Each  entity  must 
implement  the  virtual  function  sendUpdates()  defined  in  amObject.  This  function 
produces  a  RTI::HandleValuePairSet  then  calls  the  Admin: :sendEntityUpdates()  function. 
Refer  to  boid.c  in  the  code  appendix  for  listings  of  entity  functions.  Boid::sendUpdates() 
first  creates  a  Handle ValuePairSet  with  the  attributes  in  it  that  it  wants  to  update.  Then  it 
calls  Admin:  :sendEntityUpdate()  and  passes  it  the  Objectld  of  the  entity  to  be  updated,  its 
HandleValuePairSet  and  the  UserSuppliedTag  which  identifies  the  module  that  the  entity 
is  modeled  by.  Admin:  :sendEntityUpdates()  then  calls  the  Admin:  :rtiAmb-> 
updateAttributeValues(  Objectld,  HandleValuePairSet,  FederationTime, 
UserSuppliedTag( ).  This  command  sends  a  packet  out  on  the  network  containing  the 
data  specified.  When  a  remote  federate  receives  the  data  the  rtiAmb  calls  the 
FederateAmbassador::discoverObject()  function  if  the  Objectld  is  not  known  to  the 
federate  or  the  Federate  Ambassador:  :reflect  Attribute  Values()  function  if  the  entity  already 
exists  in  that  federate. 
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The  AdminFederateAmbassador::  reflectAttributeValues()  function  calls  the 
Admin:  :receiveUpdate()  function.  This  function  searches  the  list  of  entities  and  then  calls 
the  Boid::receiveUpdates()  virtual  function  defined  by  the  amObject  class.  The 
Boid::receiveUpdates()  function  decodes  the  Handle ValuePair  using  the  getValue() 
method  and  updates  the  appropriate  state  variable.  It  then  deletes  the  Handle  ValuePair. 

If  the  entity  is  not  known,  the  rtiAmb  calls  the  FederateAmbassador 
::discoverObject()  function.  This  function  ensures  the  appropriate  module  is  loaded  then 
calls  Admin:  :addSimEntity()  to  ensure  the  entity  is  added  to  the  list  of  entities  displayed  by 
the  federate.  On  the  next  update,  the  entity’s  state  is  updated  using  the  previously 
described  process. 

The  process  for  interactions  is  very  similar.  An  entity  generates  an  interaction  and 
uses  its  Boid::sendInteraction()  function.  This  function  calls  the  Admin:  :rtiAmb- 
>sendInteraction()  function.  This  provides  more  flexibility  to  the  federate.  The 
interaction  is  received  on  the  remote  federates  and  the  rtiAmb  calls 
FederateAmbassador:  :receiveInteraction()  function.  This  function  then  calls  the 
Admin:  :receiveInteraction()  function  which  finds  the  affected  entity  and  calls  the 
Boid::receiveInteraction()  function.  In  this  function  the  parameters  changed  by  the 
interaction  are  modified  and  the  ParameterHandleValueSet  is  deleted. 

This  implementation  also  has  the  ability  to  delete  entities  from  the  federation.  This 
is  accomplished  using  the  RTI  functions  deleteObject  and  removeObject.  When  an  entity 
is  identified  for  deletion,  the  entity  is  deleted  locally  then  the  rtiAmb  is  notified  of  the 
deletion  through  the  deleteObject  function.  This  causes  a  network  message  that  results  in 
the  remote  federate  rtiAmbs  calling  the  FederateAmbassador:  :removeObject()  function. 
The  details  follow  for  this  implementation.  First  an  entity  identified  for  deletion  and  its 
geometry  are  deleted  from  the  local  environment.  Then  the  Admin:  :removeAmObject() 
function  is  called.  This  function  removes  the  entity  from  the  object  list  and  calls 
Admin:  :rtiAmb->deleteObject()  which  results  in  a  call  to  the 
FederateAmbassador:  :removeObject()  function.  This  function  then  calls  the 
Admin:  :removeAmObject()  on  the  remote  federate.  This  process  notifies  the  federation  of 
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the  entities  to  be  deleted  and  makes  the  calls  necessary  to  remove  the  entity  from  the 
object  lists  in  all  federates. 

4.  RTI  Services 

The  final  topic  concerns  how  the  rtiAmb  is  allocated  processing  time.  The  RTI  is  a 
single  threaded  application,  so  processing  time  is  allocated  through  the  use  of  the  tick() 
command.  This  command  causes  the  rtiAmb  to  accomplish  tasks  such  as  clearing  buffers 
and  executing  callbacks  based  on  the  status  of  the  federation. 

The  tick()  function  has  two  forms.  The  form  used  in  the  implementation  ticks  the 
rtiAmb  once  for  each  call.  The  other  form ,  tick(min,max),  will  tick  the  rtiAmb  for  a 
specific  length  of  time.  Both  forms  return  a  boolean  value  indicating  if  there  are  more 
events  in  the  queue.  This  function  must  be  run  periodically  in  order  for  the  federation  to 
operate.  Waiting  too  long  to  tick  can  result  in  overfull  buffers  that  take  an  inordinate 
amount  of  time  to  clear  thus  reducing  the  overall  speed  of  the  federation.  In  this 
implementation  the  rtiAmb  is  ticked  once  per  frame  to  provide  the  most  updated 
information  to  each  federate. 

D.  DEMO  INSTRUCTIONS 

❖  Start  the  RTI  executive. 

❖  Open  two  command  windows. 

❖  In  both  command  windows,  change  directory  to  the  bamboo  directory. 

❖  Type  bamboo  amHLAAdmin  in  both  windows. 

>  CTRL-E  exits  amHLAAdmin  ( mouse  must  be  in  the  execution  window ) 

>  The  federation  execution  (fedex)  should  have  started  in  another  window 

>  There  should  be  two  light  green  windows  ( move  the  top  one  to  see  the  other ) 

❖  Now  add  modules  to  the  federation. 

>  Add  the  Arena  Terrain. 

■  Type  CTRL-L  to  load  module. 

■  Enter  the  module  name  airiArena. 

■  Type  CTRL-T  to  promulgate  the  module  to  all  federates. 

❖  Now  populate  the  environment. 
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>  Type  CTRL-L  to  load  module. 

>  Enter  the  module  name  amBoid. 

>  Type  B  to  create  the  Boid. 

■  Control  the  boid  with  the  arrow  keys. 

■  The  A  key  makes  it  go  forward. 

■  The  S  key  makes  it  go  backward. 

❖  Do  the  above  in  both  windows. 

>  Turn  the  boid  that  you  can  the  other  in  both  windows. 

>  Collide  one  boid  with  the  other. 

■  This  produces  an  interaction. 

■  After  10  hits  the  boid  is  destroyed  and  should  disappear. 

■  To  add  another  boid  type  B  again. 
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This  is  the  text  from  the  module.txt  file. 


amHLAAdmin  Files 


Bambool . Ob 
4 

npsVisualModule 
bbK  ey bo  a  r dM  odu 1 e 
nps  FlyingCamer aModu  Le 
amPageModule 


//  . . . - 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  module. h 
ft 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

//  Description:  This  file  defines  the  global  functions  required  by 
II  every  dynamically- linked  library.  How  these  functions  are 
//  implemented  is  arbitrary,  but  it  is  useful  have  RCS 
//  automate  some  of  the  work. 

// 

//  September  1998,  Masters  Thesis 
//  . * . * . * . . 


iifndef  _ module 

•define  _ module 

//  . . * . . . 

//  FUNCTION  PROTOTYPE  SPECIFICATIONS 
//  * . ***** . ***** . * . 

•ifdef  cplusplus 

extern  *C*  { 

•endif 


//  . * . * . . 

//  EXECUTIVE  SUMMARY 
II 

II  File  Name:  module. c 
// 

II  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
II 

//  Description:  This  file  defines  the  global  functions  required  by 
//  every  dynamically- linked  library.  How  these  functions  are 

//  implemented  is  arbitrary,  but  it  is  useful  have  RCS 

it  automate  some  of  the  work. 

// 

//  September  1998,  Masters  Thesis 

//  . ***** . . . 

//  . . . . * . . . 

//  INCLUDES  AND  EXTERNS 

// . . . . . . . . . 

•include  <stdlib.h>  //  atof 
•include  ‘module. h" 

•include  * amHLAAdmin .h" 

//  ******* . * . 

//  CODE 

// . . . . . . . 

const  char  ‘getModuleName ( > 

{ 


return  ‘amHLAAdmin*; 


SIM_API  const  char  "getModuleName ( ) ; 
SIM_API  float  getModuleVersionU ; 
SIM_API  const  char  ‘getModuleDate ( ) ; 
SIK_API  const  char  ‘getModuleText  < ) ; 
SIM.API  bool  initModule ( > ; 

SIK_API  bool  exitKoduleO; 


) 

float  getModul eVersion ( ) 
{ 

return  1.0; 

1 


•ifdef  _ cplusplus 

}; 

•endif 

•endif  II  _ module 


const  char  *getModuleDate ( ) 

{ 

return  ‘1998/08/01  06:05:48*; 

3 

const  char  “getModuleText { ) 

{ 

return  ‘amHLAAdmin  Module  --  CNTL-E  to  exit*; 

> 


bool  initModule () 

t 

ini tAdmin { ) ; 
return  1; 

> 


bool  exitModule() 

C 

exi tAdmin { ) ; 
return  1; 

} 
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//  * . * . . . . . * . 

II  Function  Name:  exitAdroinO 

//  Task:  deletes  callbacks  etc  to  ensure  the  module  is  unloaded 
If  gracefully 

II  Return  Value:  void 

U  * . . . * . . . . . ****** 

void  exitAdmin ( ) { 

bbCallback*  callback; 

bbEventResponse*  event Response; 

bbCa 1 lba  ckHand 1 e r  *  callbackHandler; 

Ada in : : getMutex { ) - >acqu ire { ) ; 

//  delete  keyboard  callbacks 
//  exit  key 

eventResponse  =  bbEventResponse :: findObject [ *amHLAAdminER_Exit* ) ; 
callback  =  bbCallback findObject  ( *amHLAAdmin_Exif  )  ; 
eventResponse->removeCallback (callback) ; 
delete  callback; 

//  resign  federate 
Admin : :resignFederate ( ) ; 

H  delete  Admin  instance 

Admin*  tmp  =  Admin : :getlnstance  () ; 

delete  tmp; 

Admin: : getMutex () ->release() ; 
exit (0) ; 


//  . . . . . . 

//  Function  Name:  initDisplayWindowO 

//  Task:  inits  main  window  for  the  federate.  Bamboo  currently  only 
//  allows  on  window  open  at  time.  This  is  the  window  for  the 
II  federate 
//  Return  Value:  void 

//  * . * . * . . . ****** . 

void  initDisplayWindowO  { 

void  preDrawFunc (bbObject  ‘object,  bbData  “data); 


window- >  se  tName ( “ AdminWindow* ) ; 

viewport  =  new  npsViewport (0 . Of ,  l.Of,  O.Of,  l.Of); 
viewport->setName(*AdminViewport“) ; 

//  camera  to  view  the  area 
camera  =  new  npsCamera ( ) ; 
camera->setName ( * AdminCamera* ) ; 
camera->setFarClip (200 . Of ) ; 
position. set(0. Of ,  3. Of,  10. Of); 
camera->setPosition (position) ; 

eamera->setClearColor(0.66f.  l.Of,  0.66f.  l.Of); 
camera->setAspectMode (npsCamera : :CALC_VERT) ; 
viewport ->setCamera (camera) ; 

window- >addViewport (viewport) ; 

//  callback  to  change  position  of  camera  and  update  screen 
callback  =  npsVisual : :drawCallback { ) ; 
callbackHandler  =  callback->getPreCallbackHandler ( ) ; 
callback  =  new  bbCallback () ; 
callback->setName ( *amHLAAdmin_preDraw” ) ; 
callbaek->setFune (preDrawFunc) ; 
callbackHandler->addCallbackLast (callback) ; 


} //initDisplayWindow 


II  Function  Name:  preDrawFunc () 

//  Task:  calls  Admin: : display  to  update  simulation  entities 
//  Return  Value:  void 

//  . . . . . . * . . . 

void  preDrawFunc (bbObject  “object,  bbData  “data) { 

Admin: :getlnstanee ( ) ->display () ; 

}ll  end  preDrawFunc 


II  . . . . . . * . . . * . . 

H  Function  Name:  crea teMainCal lba ckHand 1 er () 

II  Task:  puts  callback  on  the  bamboo  main  event  loop,  this  is  done 
U  because  RTI  1.0-3  requires  that  the  R7I  be  ticked  from  the 

I l  same  thread  that  instantiated  it 

//  Return  Value;  void 

n  . . . . . . . 


npsWindow 


'window ; 


void  createMainCal IbackHandler ( )  ( 

void  hlaTickRTI (bbObject  -object,  bbData  -data); 

bbCallback*  callback; 

bbCal IbackHandler*  eallbackHandler; 

ca 1 lba  ckHandler  =  bbCal IbackHandler: : f indob ject { 'mainCa 1 IbackHandler “ ) ; 

callback  =  new  bbCal lba ck O ; 

callbaek->setName  ( “rtiTick*  ) ; 

cal lback->setFunc (hlaTickRTI)  ; 

cal lbackHandler->addCallbackLast (callback) ; 

}  //  end  createMainCal IbackHandler ( ) 


//  * . * . * . * . ******* 

//  Function  Name:  initKeyboardModule 
//  Task:  creates  module  keyboard  callbacks 

//  Return  Value:  void 

//  . **** . 

void  initKeyboardModule ( )  ( 

void  exitFunc(bbObjeet  -object.  bbData  -data); 
void  hlaUpdateBoid (bbOb j ect  -object,  bbData  -data); 
void  hlaTickRTI (bbOb ject  -object.  bbData  -data); 
void  hlaUpdateOb ject (bbOb ject  -object,  bbData  -data) ; 
void  hlaUpdateClass (bbObject  -object,  bbData  -data) ; 

bbKeyboard  -keyboard; 

bbEventResponse  -eventResponse; 

bbCallback  -callback; 

//  get  the  keyboard  device 
keyboard  =  bbKeyboard ::  gednstance  ()  ; 

//  set  up  exit  key 
eventResponse  =  new 

bbEventResponse (bbKeyboard: :KEY_E  |  bbKeyboard: :CTRL_MASK  | 
bbKeyboard:  : DOWN_TRANS)  ; 

eventResponse->setName ( “ amHLAAdmin ER_ Exit*) ; 
callback  =  new  bbCallback () ; 
callback->setName ( -amHLAAdmin_Exif ) ; 
callback->setFunc (exitFunc) ; 
eventResponse->addCallbackLast (callback) ; 
keyboard->addEventResponse (eventResponse) ; 

)//end  initKeyboardModule ( ) 


//  * . **** . ******** . . . 

//  Function  Name:  exitFunc 

//  Task:  eallbck  function  for  cntrl-e  that  exits  the  federation  and 

//  ensures  all  callbacks  are  cleaned  up 

//  Return  Value:  void 

//  . . * . . . . ****** . 


y  -  bbMouse : :getY ( ) ; 
bbScreen : : norma lizeVal (&x. iy) ; 

if  (viewport->getWindow{ ) ->isValInside (x, y) ) t 
flag  =  1; 

) 

return  flag; 

}//  end  mouselnWindow ( ) 


//  end  amHLAAdmin -C 


void  exitFunc (bbObject  -object,  bbData  *data){ 
int  mouselnWindowf) ; 

bbModule  -module; 

i f  ( mousel nWindow  ( ) ) { 

module  =  bbModule :: f indOb j ect ( -amHLAAdmin- ) ; 
if  <!module)( 

cout  «  -amHLAAdmin  is  not  currently  loaded. .. ignoring*  «  endl 
return  ,- 
)//end  if 

if  (! bbModule : :unload(module) ) { 

cout  «  *  Error  unloading  amHLAAdmin  *  <<  endl; 

cout  «  ‘  Fatal  Error  -  aborting  executable!*  «  endl  <<  endl; 

exit (0) ; 

)//  end  if 
}//end  if 

)//  exitFunc () 


//  . *** . * . ***** . . . 

//  Function  Name:  hlaTickRTI 

II  Task:  callback  func  that  makes  the  RTI  calls  that  tick  the  rti 

//  this  provides  the  cpu  time  for  the  rti  to  get  its  work  done 

II  Return  Value:  void 

l!  ***** . * . * . . 

void  hlaTickRTI (bbObject  -object,  bbData  -data)  { 

RTI: : FederationTime  tmpTime(l.O) ; 
while  (Admin:  :  gednstance  ( )  ->tickRTI  ( ) )  ; 

Admin: :getlnstance ( ) ->update Federation (tmpTime) ; 

}//  end  hlaTickRTI () 


//  . . . . . . 

//  Function  Name:  mouselnWindow 

//  Task:  ensures  the  mouse  pointer  is  the  window  that  you  want  to 

//  update 

//  Return  Value:  integer  that  is  interpreted  for  use  as  a  bool 
//  . . . —  . . * . . 

int  mouselnWindow ( )  l 
int  flag  =  0; 

npsWindow  -window; 

npsViewport  -viewport; 

window  a  npsWindow: : findOb ject ( -AdminWindow" ) ; 

viewport  =  npsViewport: :findObj ect ( "AdminViewporf ) ; 

float  x,y; 

x  =  bbMouse: :getX( > ; 


// . . . * . . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  admin. h 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

//  Description:  Definition  of  Admin  class 

//  This  file  defines  the  utility  and  external  API  functions 
//  required  to  manage  an  amCompatible  federate 

// 

//  September  1998,  Masters  Thesis 

II . . . . . . . . 

♦include  -Rti.hh” 

•include  -AdminFederateAmbassador .h" 

•include  *npsVec3f.h* 

•include  -npsGeometry .h" 

•include  * bbKeyboard. h' 

•include  “amObjecc.h" 

•ifndef  _adnin 
•define  _admin 


//defines 


•ifndef  SIM_API 
tifdef  VISUALCPP 

•define  SIM_API  _ decl spec (dll import) 

•  else 

•define  SIM_API 
•endif 
•endif 


class  SIM_API  Admin 


//member  variables 
public: 

//  Simulation  Entity  data  memebers 

static  vector<amObject->  ras_amObjectArray; 

static  unsigned  int  ms_NumberAmObjects; 

//  Array  of  Objects  used  by  modules 
static  vector<amObject*>  ms_ModuleArray; 
static  unsigned  int  ms_NumberModules; 

//  The  Terrain  Object  pointer 
static  amObject-  ms_Terrain; 

//  time  management  variables 

static  RTI;: Boolean  ms_timeAdvGrant ; 

static  RTI :: FederationTime  ms_grantTime; 


static  RTI :  : FederationTime 


m_lastTime; 


//  RTI  Ambassador  pointer 

Static  RTI: : RTIambassador *  ms_rtiAmb; 

static  RTI: : FederateHandle  m_£ederateID; 


//  flag  that  signals  whether  interactions  are  valid 
Static  RTI::Boolean  ms_InceractionFlag ; 

//  name  of  the  Federation  Execution 
static  char*  const  m_FedExecName; 

//  provides  url  to  module  locations 
static  char*  const  ms_ModuleURL; 


private: 

//  Static  Member  Data 

//  Federate  Ambassador  Pointer 

static  AdminFederateAmbassador*  ms_fedAmb; 


//  RTTI  data  provided  by  the  RTI  during  Init{) 
static  RTI : :0b jeetClassHandle  ms_AdminClassHandle; 

static  RTI: : AttributeHandle  ms_ModuleURLAttrHandle; 

static  RTI: : AttributeHandle  ms_Modu leVersionAtt r Handle ; 

static  RTI :: AttributeHandle  ms_ModuleNameAttrHandle; 

static  RTI: : Ob jeetClassHandle  ms_ESClassHandle; 

static  RTI : : AttributeHandle  ms_PositionAttrHandle; 

static  RTI: : AttributeHandle  ms_OrientationAttrHandle; 

static  RTI: : AttributeHandle  ms_VelocityAttrHandle; 

static  RTI: : AttributeHandle  ms_AmiminitionAttrHandle; 

static  RTI :: AttributeHandle  ms_DamageAttrHandle; 

static  RTI: : Interact ionClassHandle  ms_CollisionInteractionHandle; 
static  RTI : : ParameterHandle  ms_EntityIdHandle; 


//  Names  for  querying  RTTI  values 

static  char*  const  ms_ESClassStr; 

static  char*  const  ms_PositionStr ; 

static  char*  const  ms_OrientationStr; 

static  char*  const  »s_VelocityStr; 

static  char*  const  ms_AmmunitionStr; 

static  char*  const  ms_DamageStr ; 

static  char*  const  ms_CollisionInteractionStr ; 

static  char*  const  ms_EntityIdStr; 

ft  constructor  is  private  due  to  singleton 
Admin ( ) ; 

//  singleton 
static  Admin  *this_; 


Static  RTI:: Boolean  tiekRTI ( )  ; 

static  RTI : : Boolean  tiekRTI (RTI : :TickTime  minTick, RTI : :TickTime  maxTick] ; 

static  void  advanceTime (RTI : : FederationTime  time); 

static  void  resignFederate ( ) ; 

static  void  joinFederation ( ) ; 

static  void  setTimeManagement ( ) ; 

static  void  createFederationExecution ( ) ; 

static  void  Init(  }; 

static  void  PublishAndSubscribe () ; 

static  ACE_Recursive_Thread_Mutex*  getMutexf); 


U  Accessor  Methods 
//  Static  Accessor  Methods 

static  RTI: :0b jeetClassHandle  getESClassHandle ( ) 

(  return  ms_ESClassHandle;  ); 

static  RTI: : AttributeHandle  getPositionAttrHandle ( } 

{  return  ms_PositionAttrHandle;  ); 
static  RTI: : AttributeHandle  getOrientationAttrHandle ( ) 

(  return  ms_OrientationAttrHandle;  ); 
static  RTI: : AttributeHandle  getVelocityAttrHandle( } 

(  return  ms_VelocityAttrHandle;  ); 
static  RTI: : AttributeHandle  getAmmunitionAttrHandle 0 

(  return  ms_AmmunitionAttrHandle;  >; 
static  RTI :; AttributeHandle  getDamageAttrHandle () 

{  return  ms_DamageAttrHandle;  ) ; 

static  RTI: : Interact ionClassHandle  getCollisionlnteractionHandle ( ) 
{return  ms_CollisionInteractionHandle; } 

static  RTI :: AttributeHandle  getEntityldHandle () 

{  return  ms_EntityIdHandle,-  }; 


};  //  end  Class  Admin 
♦endif 


It  mutex  used  to  make  Admin  Thread  Safe 
static  ACE_Recursive_Thread_Mutex  adminMutex; 

//  member  functions 
public: 

//  destructor 
virtual  -Admin (); 

//  ensures  update  of  the  federation 

void  updateFederation(RTI:  :FederationTimeE,  newTime); 

ft  This  is  Che  Admin  API  portion 

//  singleton  getter 
static  Admin  'getlnstance ( ) ; 

//  Send  data  to  RTI 

static  void  sendCollisionlnteraccion (RTI :: FederationTime  theTime. 

RTI: :ObjectID  oid) ; 

static  void  sendEntityUpdate (RTI: :ObjectID  theObject, 

RTI: :AttributeHandleValuePairSett  theAttributes . 
const  RTI: : UserSuppliedTag  theTag); 


//  Receive  data  from  RTI 

static  void  receiveUpdace (  RTI: :ObjectID  theObject, 

const  RTI : : AttributeHandleValuePairSett  theAttributes, 

RTI :: FederationTime  theTime, 

const  RTI :: UserSuppliedTag  theTag, 

RTI: : EventRetractionHandle  theHandle  ); 

static  void  receiveInteraction(RTI : :InteractionClassHandle 
thelnteraetion, 

const  RTI : : ParameterHandleValuePairSettt  theParameters , 

RTI : : FederationTime  theTime, 
const  RTI :: UserSuppliedTag  theTag, 

RTI : : EventRetractionHandle  theHandle) ; 

//  Manage  Sim  Entity  Pointers 
static  void  displayO; 

static  void  addModuleFunctionPointer (amObject*) ; 
static  amObject*  f indSimEntity (RTI : :ObjeetID  objectld  ); 

static  amObject*  f indSimEntity (const  char  *  moduleName); 

static  RTI : :0b jectID  registerObject ( ] ; 

static  amObject*  addSimEntity (const  char*  moduleName,  RTI : :0b jectID) 
static  amObject*  checkEntityCollision (amObject*  that); 
static  void  removeAmObject(RTI: :ObjectID  oid); 

//  Module  Object  Management 

static  RTI: :Boolean  moduleLoaded (const  char*  moduleName); 
static  void  loadModule ( const  char*  moduleName); 
static  void  unloadModule (const  char*  moduleName); 
static  amObject*  findModule (const  char*  moduleName); 
static  void  removeModule{ const  char*  moduleName); 

//  RTI  execution  management 


//  . * . ****** . . 

H  EXECUTIVE  SUMMARY 
it 

If  File  Name:  admin. c 
tt 

It  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 

// 

tt  Description:  Method  Definitions  of  Admin  class 

//  This  file  defines  the  utility  and  external  API  functions 

it  required  to  manage  an  atnCompatible  federate 

tt 

tt  September  1999,  Masters  Thesis 

it  ***** . ************ . . . . 

♦include  *RTI . hh" 

♦include  ’admin. h* 

♦include  * AdminFederateAmbassador . h* 

♦include  ‘npsGeometry .h* 

♦include  *bbKeyboard.h" 

♦include  "bbModule.h" 

♦include  "amObject. h* 

♦include  "ace/OS.h" 

♦include  * vector. h* 


//  Static  Variable  initializations 

//  singleton 

Admin  * Admin : : this_  =  0; 

RTI: : RTIambassador*  Admin : :ms_rtiAmb  =  NULL; 
AdminFederateAmbassador*  Admin: :ms_fedAmb  =  NULL; 
RTI: : FederateHandle  Admin: :m_federateID  =  0; 
vector<amObject*>  Admin: :ms_amOb jectArray; 
unsigned  int  Admin: :ms_NumberAmObjects  =  0; 
vector<amObject*>  Admin: :ms_ModuleArray; 
unsigned  int  Admin: :ms_NumberModules  =  0; 
amObject*  Admin: :ms_Terrain  =  NULL; 


it  Time  Management  flags 

RTI:: Boolean  Admin : :tns_timeAdvGrant  =  RTI : : RTI_FALSE; 

RTI : : FederationTime  Admin : : ms_grantTime { 1 . 0 ) ; 

RTI: : FederationTime  Admin: :m_lastTime; 

RTI : : Boolean  Admin: :ms_InteraetionFlag  s  RTI : : RTI_FALSE ; 


//  RTTI  data 
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RTI : ;ObjectClassHandle 
RTI : : Attr ibuteHandle 
RTI: :AttributeHandle 
RTI: ; Attr ibuteHandle 
RTI: : Attr ibuteHandle 
RTI: :AttributeHandle 

RTI: : InteractionClassHandle 
RTI: :ParameterHandle 


Admin : :ms_ESCl«ssHandle  -  0; 

Admin: :ms_PositionAttrHandle  =  0; 

Admin: :ms_OrientationAttrHandle  =  0; 
Admin: ;ms_VelocityAttrHandle  =  0; 

Admin : :ms_AmmunitionAttrHandle  a  0; 
Admin : :ms_DamageAttrHandle  =  0; 

Admin :: ms _CollisionInteractionHandle  =  l 
Admin: :ms_EntityIdHandle  =  0; 


//  Names  for  querying  RTTI  values 


char*  const 
char*  const 
char*  const 
char*  const 
char*  const 
char*  const 


Admin 

Admin 

Admin 

Admin 

Admin 

Admin 


ms_ESClassStr  =  “EntityState* ; 
ms_PositionStr  =  'Position* ; 
ms_OrientationStr  =  "Orientation* 
ms_VelocityStr  =  "Velocity*? 
ms_AmmunitionStr  =  "Ammunition*; 
ms_DamageStr  a  “Damage"; 


try  //  rtiAmb 
( 

Admin:  :ms_rtiAmb  =  new  RTI ::  RTI  ambassador  ()  ; 

Admin  :  :ms_fedAmb  =  new  AdminFederateAmbassadorO  ; 

)  //  try  rtiAmb 

catch  {RTI :  : ConcurrentAceessAttemptedfc  e) 

{ 

cerr  «  "Instantiate  rtiAmb  and  fedAmb*  «  endl; 
cerr  «  Ue  «  endl; 

> 

catch  {RTI :: Exceptioni  e) 

{ 

cerr  «  "Instantiate  rtiAmb  and  fedAmb*  «  endl; 
cerr  «  s>e  «  endl; 


char*  const 
char*  const 


Admin: :ms_CollisionInteractionStr  =  "Collision* ,- 
Admin: :ms_EntityIdStr  =  "EntitylD"; 


char*  const  Admin: :m_FedExecName  =  *HLA_Admin"; 

char*  const  Admin: :ms_ModuleURL  =  "URL  not  defined"; 


createFederationExecution { J ; 
joinFederation  ( ) ; 

)//  end  constructor 


ACE_Recursive_Thread_Mutex  Admin: :adminMutex; 


///////////////////////////////////////////////////////////////////// 
//  Construction/Destruction 

////////////////////////////////////////////////////////////////////// 


//  ***** . . . * . . 

//  Function  Name:  ge t Instance U 
//  Task:  singleton  accessor  function 
//  Return  Value:  Admin* 

// . * . . . . 

Admin*  Admin: : get Instance! ) { 

if  ( ! this_)  { 

this_  -  new  Admin () ; 

) 

return  this_; 

}//end  getlnstanee () 


//  . . . 

//  Function  Name:  Admin {) 
//  Task:  constructor 
//  Return  Value:  none 
n  . . * . 

Admin :: Admin ! }  { 


ptr-- ; 

) 

ms_Modu le Array. empty { ) ; 

getMutex { ) ->release( ) ; 

//  delete  ms_Terrain 
if (ms_Terrain)  delete  ms_Terrain; 

//  delete  the  ambassadors 
if (ms_rtiAmb)  delete  ms_rtiAmb; 
if (ms_fedAmb)  delete  ms_fedAmb; 


//  . . . . . . . . . . . 

//  Function  Name:  f indSimEntity (  RTI: : Object ID  objectld  ) 

//  Task:  find  a  simulation  entity  given  its  Object  ID 
//  Return  Value:  amObject* 

//  . . . . . . 

amObject*  Admin :: f indSimEntity (  RTI : :Ob j ectID  objectld  )( 

amObject*  amPtr  =  NULL; 
amObject*  tmp  =  NULL; 

vector<amObjeet*> : :const_iterator  ptr; 
getMutex { ) ->aequire ( ) ; 

//  iterate  the  vector  ms_amObject Array 

for  (ptr  =  ms_amObjeetArray .begin! ) ;  ptr  !=  ms_amObject Array. end { ) ; 
ptr**)  { 

tmp  =  (amObject* )( *ptr) ; 

if (tmp  it  (tmp->getEntityID()  ==  objectld))! 
amPtr  =  tmp; 
break; 

} //end  if 
J //end  for 

getMutex ( ) ->release ( ) ; 

return  amPtr; 

)//  end  f indSimEntity 


//  . . . . . . . . 

It  Function  Name:  f indSimEntity (  const  char*  moduleName  ) 
//  Task:  find  a  simulation  entity  given  its  Module's  name 
//  Return  Value:  amObject* 

// . . . . 

amObject*  Admin: :f indSimEntity!  const  char*  moduleName  )( 

amObject*  amPtr  -  NULL; 
amObject*  tmp  =  NULL; 


//  Function  Name:  -Admin () 
l l  Task:  destructor 
It  Return  Value:  none 
//  . . . . . . 

Admin : : -Admin ( ) { 
amObject*  tmp; 

vector<amObject*> :: iterator  ptr; 

getMutex { ) ->acquire ( ) ; 

//delete  all  elements  of  Object  Array 
ptr  =  ms _amObjectArray. begin!)  ; 
whilefptr  i-  ms_amObjectArray .end! ) ) { 
tmp  -  (amObject* ) *ptr; 
if (tmp) ( 

delete  tmp; 

) //end  if 
ptr++ ; 

) 

ms_am0bj ect Array,  empty () ; 

//delete  ms_ModuleArray 
ptr  a  ms_ModuleArray .begin ()  ; 
while(ptr  !=  ms_ModuleArray.end() ) ( 
tmp  =  (amObject* ) *ptr; 
if (tmp) { 

delete  tmp; 

)//end  if 


vector<amObject*> : :const_iterator  ptr; 
getMutex ( ) ->acquire  < ) ; 

//iterate  the  vector 

for  (ptr  =  ms_amObj  eetArray .  begin  [)  ;  ptr  5=  ms  _amObj  ect  Array .  end  ( )  ; 
ptr**) { 

tmp  =  (amObject*) (*ptr) ; 

if (tmp  &&  strcmp (moduleName, tmp->getModuleName () )  ==  0)  ! 
amPtr  =  tmp; 
break; 

)//end  if 
)//end  for 

getMutex ( } ->release { )  ; 

return  amPtr; 

)//  end  finds imEntity 


//  . . . . . . . . . 

//  Function  Name:  registerObject ( ) 

//  Task:  ask  the  RTI  for  a  unique  Object  ID 

//  register  the  Object  as  and  Entity  State  Object  in  the  RTI 
//  Return  Value:  RTI : : Object ID 

//  . . . . . . . 

RTI : :0b jectlD  Admin: : registerObject () { 

RTI : : Object  ID  oid  =  0; 
if  (  Admin: :ms_rtiAmb  ){ 
getMutex ( ) ->aequire ( ) ; 

RTI : :ObjectIDcount  numObjects (1 ) ; 

//  get  the  ID  from  the  RTI 
try  ( 

Admin: :ms_rtiAmb->requestID(  numObjects.  oid,  oid  ); 

} 

catch  (RTI :: Except ionfc  e) 
t 

cerr  «  “requestID*  «  endl; 
cerr  «  &e  «  endl; 

} 

//  register  the  ID  as  an  Entity  State  Class  Object 
try! 

Admin : :ms_rtiAmb->registerOb ject (  Admin; : getESClassHandle () ,  oid  ); 

} 

catch  (RTI:  : Except ionlr  e) 

{ 

cerr  «  “registerObject*  «  endl; 
cerr  «  &e  «  endl; 

> 
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getMuteX ( ) ->release ( ) ; 


Admin: :ms_AmmunitionAttrHandle  =  Admin ::  sns_r  t  lAmb 
>getAttributeHandle (ms_AmmunitionScr , 


ms_ESClassHandle) ; 


)//  end  register  object 


//  Function  Name:  Init (  ) 

U  Task:  requests  the  handle  values  for  the  user  defined  objects 
//  the  FED  file  from  the  RTI 
//  Return  Value:  void 


yoid  Admin:: Init {  ){ 


acch  (RTI: : Exceptions.  e>  { 

cerr  «  “getAttributeHandle*  «  endl; 
cerr  <<  fce  <<  endl; 


Admin:  :ms_ DamageAttrHandle  =  Admin :  :ms_rtiAmb- 
>getAttributeHandle (ms_DamageStr , 


tatch  (RTI :: Exceptions,  e)  { 

cerr  «  'getAttributeHandle*  «  endl; 
cerr  «  fce  «  endl; 


if  (  Admin: :ms_rtiAmb  ) { 

//  RTTI  for  Objects 
try{ 

Admin : :ms_ESClassHandle  =  Admin::ms_rtiAmb- 
>getObj ectClassHandle (ms_ESClassStr ) ; 

) 

catch  (RTI : :  Exceptions.  e){ 

cerr  «  “getObjectClassHandle*  «  endl; 
cerr  «  fce  «  endl; 


Admin: :ms_PositionAttrHandle  =  Admin : :ms_rtiAmb- 
>getAttributeHandle (ms_PositionStr . 


//  RTTI  for  Interactions 
try{ 

Admin: :ms_CollisionInteractionHandle  a 
Admin: :ms_rtiAmb- 

>getInteractionClassHandle (ms_CollisionInteractionStr } ; 

) 

catch  (RTI ::  Except  ions,  e)  ( 

cerr  «  "getlnteractionClassHandle*  «  endl; 
cerr  «  s<e  «  endl; 

) 

try{ 

Admin: :ms_EntityIdHandle  = 

Admin: ;ms_rtiAmb->getParameterHandle (ms_EntityIdStr , 
ms_CollisionInteractionHandle) ; 


catch  (RTI:  : Exceptions,  e)  { 

cerr  «  ■getAttributeHandle’  «  endl; 
cerr  <<  fee  «  endl; 

) 

tryC 

Admin: :ms_OrientationAttrHandle  =  Admii 
>getAttributeHandle (ms_OrientationStr, 


catch  (RTI :: Exceptions,  e)  { 

cerr  «  *getParameterHandle*  «  endl; 
cerr  «  s.e  «  endl; 


>//  end  if 
)//  end  Init 


catch  (RTI: : Except ioni  e)  ( 

cerr  <<  “getAttributeHandle*  «  endl; 


Admin : :ms_VelocityAttrHandle  =  Admin: : ms _rtiAmb- 
>getAttributeHandle (ms_VelocityStr , 


:atch  (RTI: : Exceptions,  e)  { 

cerr  <<  "getAttributeHandle*  «  endl; 
cerr  «  fce  «  endl; 


//  Function  Name:  PublishAndSubscribe (> 

1 1  Task:  informs  the  RTi  that  this  federate  will  publish  and  subscribe 
II  Entity  State  Objects  and  Collision  Interactions 
//  Return  Value:  void 


oid  Admin: : PublishAndSubscr ibe { ) ( 
if  (  Admin: :ms_rtiAmb  ){ 


//  To  actually  subscribe  and  publish  we  need  to  build 


//  an  AttributeHandleSet  that  contains  a  list  of 
//  attribute  type  ids  (AttributeHandle) . 


RTI: : AttributeHandleSet  ‘ESClassAttributes; 


etch  (RTI : : Exceptions,  e)  { 

cerr  «  *RTI :: AttributeHandleSet Factory: : create*  «  endl; 


try  { 

ESClassAttributes->add(ms_PositionAttrHandle) ; 

) 

catch  (RTI: : Exceptions,  e)  { 
cerr  <<  "add"  «  endl; 
cerr  «  fce  «  endl; 

) 

try  ( 

ESClassAttributes->add(ms_OrientationAttrHandle) ; 

} 

catch  (RTI :: Exceptions,  e)  { 
cerr  «  'add*  «  endl; 


try  { 

ESClassAttributes- >add(ms_VelocityAttrHandle) ; 

} 

catch  (RTI: : Exceptions,  e)  ( 
cerr  <<  “add*  «  endl; 
cerr  «  fce  <<  endl; 


try  { 

ESClassAttributes->add(ms_AmmunitionAttrHandle) ; 

) 

catch  (RTI: : Except ion&  e)  { 
cerr  <<  “add*  <<  endl; 
cerr  «  S.e  <<  endl; 


cerr  «  Sie  «  endl; 


try  ( 

Admin: :ms_rtiAmb->publishObjeetClass ( 
ms_ESCl a  ssHand le . ‘ESClassAttributes) ; 

J 

catch  (RTI:  : Exceptions,  e)  { 

cerr  «  "publishObjectClass*  «  endl; 
cerr  «  s.e  «  endl; 

) 

try  ( 

Admin: :ms_rtiAmb- 

xsubscribelnteractionClass (ms_Coll isionlnteraetionHandle) ; 

) 

catch  (RTI: : Exceptions,  e)  ( 

cerr  «  *subscribeObjectClassAttribute*  «  endl; 
cerr  «  he  «  endl; 


try  { 

Admin: :ms_rtiAmb->publishInteractionClass  ( 
ms_CollisionInteractionHandle) ; 

) 

catch  (RTI:  : Exceptions,  e)  { 

cerr  «  "publishlnteractionClass*  «  endl; 
cerr  «  fce  <<  endl; 


ESClassAttributes->empty ( ) ; 

delete  ESClassAttributes;  //  Deallocate  the  memory 
) //end  if 


)//end  publish  and  subscribe 


//  Function  Name:  createFederationExecution ( ) 

//  Task:  makes  RTI  call  that  creates  the  federation  execution  if 
//  does  already  exist 

//  Return  Value;  void 


ESClassAttributes - >add { ms_DamageAt  trHand 1 e ) ; 

:atch  (RTI: :  Except  ions,  e]  ( 
cerr  «  “add"  <<  endl; 
cerr  <<  s.e  <<  endl; 


rateFederationExecution ( ) { 


cout  «  “createFederationExecution*  «  endl; 


try  ( 

Admin: :ms_rtiAmb->subscribeOb jectClassAttribute (  ms_ESClassHandle 

•ESClassAttributes  ); 

J 

catch  (RTI:  : Exceptions,  e)  ( 

cerr  <<  •subseribeObjectClassAttribute"  <<  endl; 


//A  successful  createFederationExecution  will  cause 
//  the  fedex  process  to  be  executed  on  this  machine. 

// . - . 

Admin: :ms_rtiAmb->createFederationExecution (  w_FedExecName  ); 
Sleep (2000) ; 


catch  (  RTI : :FederationExecutionAlreadyExistsfc  i 
cerr  «  ‘createFederationQcecution*  «  endl; 
cerr  «  fce  «  endl; 

Sleep (500} ; 

) 

catch  (  RTI Exceptions,  e  )  { 

cerr  «  ‘createFederationExecution’  «  endl; 
cerr  «  fce  «  endl; 


eFederationExecution 


Publ i shAndSubscr ibe { ) ; 


}//  end  join  federation 


//  Function  Name:  setTimeManagement ( ) 

//  Task:  sets  the  RTI's  time  management  state 
//  This  federate  is  NOT  time  managed 
//  Return  Value:  void 


//  Function  Name:  joinFederation ! ) 

//  Task:  makes  RTI  call  that  joins  the  federation  that  has  bee: 
II  created 
II  Return  Value:  void 


iid  Admin: : joinFederation O { 

//  give  join  ten  tries  to  get  joined 
for  (int  ix=0;ix<10;  ix**)  ( 
try  { 

m_federateID  =  Admin: :ms_rtiAmb->joinFederationExecution ( 
"Sim_Admin‘ ,  m_FedExecName ,  Admin : :ms_fedAmb) ; 

break; 

J 

catch  (RTI : : FederationExecutionDoesNotExistfc  e)  { 

//  no  reason  to  get  excited  fedex  may  not  be  done 

cerr  «  *Fed  Ex  does  not  exist  trying  again*  «  endl; 
Sleep (1000) ; 


catch  (  RTI : : Except ioni  e  )  { 

cerr  <<  ‘Fatal  Error  -  Join  Failed'  «  endl; 
cerr  «  &e  <<  endl; 
exit (0 ] ; 


void  Admin :: setTimeManagement ( )  t 
try  ( 

ms_rtiAmb->setTimeConstrained{  RTI : :RTI_FALSE  ); 
ms_rtiAmb->turnRegulationOf f ( )  ; 

) 

catch  (  RTI: : Exceptions  e  ){ 

cerr  «  ‘setTimeManagement*  <<  endl; 
cerr  <<  &e  «  endl; 

) 

} / /end  setTimeManagement 


//  Function  Name:  resign Federate () 

//  Task:  deletes  federate  from  the  fedex  and  destroys  the  federate 
//  if  it  is  the  last  federation  to  resign 
//  Return  Value:  void 


void  Admin; :resignFederate ( ) { 

cout  «  ‘Resigning  from  federation"  <<  endl; 
try  { 

Admin: :ms_rtiAmb->resignFederationExecution ( 
RTI: :DELETE_OBJ£CTS_AND_REL£ASE_ATTRIBUTES) ; 


catch  (RTI :: Exceptions,  e)  { 

cerr  <<  ‘resignFederationExecution'  «  endl; 
cerr  «  s.e  «  endl; 


//Sleep  to  ensure  federate  is  joined 


setTimeManagement { ) ; 


//  The  Admin  class  needs  to  determine  what  the  RTI  is 
//  going  to  call  its  class  type  and  its  attribute’s  types. 


try  ( 

Admin: :®s_rtiAmb->destroyFederationExecution (m_FedExecName) ■ 

> 

catch  (RTI ::  Exceptions,  e) 

{ 

cerr  «  "destroyFederationExecution*  <<  endl; 
cerr  «  S.e  «  endl; 

) 

} / /end  resign Federate 


//  Function  Name:  advance? ime (RTI :: Feder at ionTime  ttime) 

//  Task:  asks  RTI  if  it  is  alright  to  advance  time  another  step 
//  Return  Value:  void 


catch  (RTI ::  Exception  fce) 

{ 

cerr  «  “tick*  «  endl; 
cerr  «  S<e  «  endl; 


void  Admin: :advanceTime (RTI : : FederationTime  ttime) { 


try  ( 

Admin: :ms_rtiAmb->timeAdvaneeRequest (ttime) ; 


catch  (RTI:  :  Exceptions,  e)  { 

cerr  <<  ‘timeAdvanceRequest *  «  endl; 
cerr  <<  &e  «  endl; 

} //catch 


>//  end  advanceTime 


//  Function  Name:  addModuleFunetionPo inter (amObj ect*  amOb j ) 

//  Task:  Adds  the  Object  associated  with  each  module  to  a  vector  that 
//  will  be  used  later  to  instance  objects  as  needed 
//  Return  Value:  void 


-oid  Admin: :addModuleFunctionPointer (amOb ject*  amObj >  ( 


//  Function  Name:  tickRTI ( ) 

//  Task:  ticks  the  RTi  providing  processing  time  to  clear  buffers 
//  Return  Value:  Boolean 


RTI : ; Boolean  Admin : : tickRTI ( ) 

{ 

RTI:: Boolean  events; 
try  ( 

events  =  Admin: :ms_rtiAm 

> 

catch  { RTI ::  Except  ion  S.e) 

{ 

cerr  «  ‘tick*  «  endl; 
cerr  <<  fce  «  endl; 
return  RTI : : RTI_FALSE; 


getMutex ( ) ->acquire { ) ; 

//  looks  for  amObj  already  in  vector 

ptr  s  find (ms _ModuleArray. begin () , ms_ModuleArray . end ( ) .amObj) ; 

//  if  amObj  in  vector  do  not  add 
if [ptr  ==  ms_ModuleArray.end() ) ( 
ms  _ModuleArray .push_back ( amObj ) ; 

} 

Admin: :ms_Number Modules**; 
getMutex () ->release() ; 

}  //  end  addModuleFunctionPointer 


//  Function  Name:  findModule (const  char*  name) 

//  Task:  returns  pointer  to  the  object  stored  in  the  object  array  that 
//  corresponds  to  a  particular  module 
//  Return  Value:  amObj ect* 


//  Function  Name:  tickRTI [RTI : :TickTime  minTick, RTI :  :TickTime  maxTick) 
//  Task:  same  as  above  except  ticks  RTI  for  a  certain  span  of  time 
//  Return  Value:  void 

//  . . . * . . * . . . . . ***** 

RTI:: Boolean  Admin: : tickRTI (RTI : :TickTime  minTick, RTI : :TickTime  maxTick) 


RTI : : Boolean  events  =  RTI : : RTI_FALSE; 


try  { 

events  -  Admin:  :ms_rtiAmb->'tick (minTick, maxTick) ; 


amObject*  Admin: : findModule (const  char*  name) ( 

amObj ect*  tmp  -  NOLL; 
amObject*  retObj  =  NULL; 

vector<amObject*> : : const_iterator  ptr; 
getMutex ( ) ->acquire ( ) ; 

for  (ptr  =  ms_ModuleArray . begin ( ) ;  ptr  !=  ms_ModuleArray ,end() ;  ptr* 
tmp  =  (amObject*)  (*ptr) ; 

if(tmp  ts.  strcmp(name,  tmp->getModuleName  [ ) )  ==  0)  ( 
retObj  =  tmp; 
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break; 

)  /  /end  if 
}/ /end  for 

getMutexO  ->release()  ; 
return  retObj ; 

)//  end  findModule 


//  ***** . * . . . * . 

//  Function  Name:  moduleLoaded (const  char*  name) 

//  Task:  boolean  function  returning  true  if  module  name  is  loaded 
//  false  otherwise 
//  Return  Value:  Boolean 

//  ***** . * . * . . . 

RTI : : Boolean  Admin: : moduleLoaded (const  char*  name) ( 

RTI:: Boolean  flag  =  RTI : : RTI_FALSE ; 
bbModule*  mod  =  bbModule :: findObject (name) ; 

if  (mod)  { 

flag  =  RTI: :RTI_TRUE; 

}//  end  if 

return  flag; 

)//  end  moduleLoaded 


//  Function  Name:  addSimEntity (const  char*  name.  RTI: :ObjectID  oid) 
//  Task;  adds  simulation  entity  to  the  amObjectArray 
//  Return  Value:  amObject* 

// . * . . . * . . 

amObject*  Admin: : adds imEntity (const  char*  name,  RTI : : ObjectID  oid) { 

amObject*  mod  -  Admin :: findModule (name) ; 
amObject*  tmp  =  NULL; 
if  (mod  UU  mod->isTerrain  () )  ( 

Admin: :ms_Terrain  =  mod->createObject (oid) ; 

)//end  if 
else  if  (mod) { 

tmp  =  mod->createObject (oid) ; 
vector<amObject*>: iterator  ptr; 

getMutex ( ) ->acquire ( ) ; 

ms_amObj  eetArray.push_.baek ( tmp) ; 

Admin: :ms_NumberAmOb jects** ; 

getMutex { ) ->release ( ) ; 

)//end  if 
return  tmp; 


//  iterate  the  amObjectArray 

for  (ptr  =  ms_amObj ectAr ray .begin () ;  ptr  !=  ms_amObjeetArray.end() ; 
ptr**) ( 

tmp  =  (amObject*) (*ptr) ; 
if (tmp)  ( 

if  1 tmp->localObjeet ( > ) { 

tmp->sendUpdates (newTime) ; 

) //end  if; 

}//end  if 
J  /  / end  for 

//  do  same  for  the  terrain 
if (ms_Terrain) ( 

if (ms_Terrain->localOb ject () ) ( 
getMutex ( ) ->acquire ( )  ; 
ms_Terrain->sendUpdates (newTime) ; 
getMutex ( ) ->release ( ) ; 

} 

)//end  if 

getMutex ( ) ->release( ) ; 

) //end  updateFederation 


//  * . ***** . * . * . . . 

//  Function  Name:  display () 

//  Task:  iterates  the  amObjectArray  telling  each  amObject  to  display 
//  its  geometry  in  the  proper  position  and  orientation 
//  Return  Value:  void 

//  . . * . . . . . . . 

void  Admin: : display!) { 
amObject*  tmp  -  NULL: 

if (ms_Terrain) ( 

ms_Terrain->display  ( )  ; 

) / / end  if 

vector<amObject*>: : iterator  ptr; 
getMutex ( ) ->acguire ( )  ; 

ptr  =  Admin: :ms_a»Object Array. begin (} ; 
whi le (ptr  ! =  Admin : : ms_amOb j ectArray . end ( ) ) { 
tmp  =  (amObject*) *ptr; 
if (tmp) 

tmp->display() ; 
ptr** ; 

) //end  while 
getMutexO  ->release( )  ; 

}//  end  display 


// 


)//  end  addSimEntity 


// . * . * . . 

//  Function  Name:  loadModule (const  char*  name) 

//  Task:  makes  bamboo  call  that  loads  the  name  module 
//  Return  Value:  void 

//  . . ****** . . . 

void  Admin: : loadModule (const  char*  name) { 
bbModule*  mod; 

getMutex ( ) ->acquire ( )  ; 

mod  =  bbModule : : load (name , ms_ModuleURL) ; 
getMutexO  ->release() ; 

)  /  /  end  loadModule 


//  . . . . . * . *****’ 

//  Function  Name:  unloadModule ( const  char*  name) 

//  Task:  makes  bamboo  call  that  unloads  the  name  module 
//  Return  Value:  void 

//  . . * . * . ***** . . 

void  Admin: :unloadModule (const  char*  name) ( 
bbModule*  mod; 

mod  =  bbModule : : f indOb j  ect (name ) ; 
getMutex ( ) ->acquire ( ) ; 
bbModule: :unload (mod) ; 
getMutexO  ->release()  ; 

}  //  end  unloadModule 


// . ***** . ******* . . . * . * . ***** 

//  Function  Name:  updateFederation (RTI :: FederationTimeS.  newTime) 

//  Task:  iterates  the  amObjectArray  telling  each  localObject  to  update 
//  the  federation  with  their  current  state 
//  Return  Value:  void 

. . . . . . . . . . . 

void  Admin:  : updateFederation  (RTI :  :  FederationTimefi  newTime)  ( 
amObject*  tmp  =  NULL; 


veetor<amObject*>: : iterator  ptr; 

getMutex ( ) ->acquire ( ) ; 


//  Function  Name:  receiveUpdate (  RTI: :ObjectID  theObject, 

//  const  RTI : : AttributeHandleValuePairSetfc  theAt tributes, 

//  RTI : : FederationTime  theTime. 

//  const  RTI: : Us erSuppl iedTag  theTag, 

//  RTI :: Event Retract ionHandle  theHandle  ) 

//  Task:  sends  the  handle  value  pair  to  the  correct  amObject. 

//  if  the  moduel  is  not  loaded  then  the  proper  calls  are  made  to 
//  load  the  module  for  the  object  to  be  updated 
//  Return  Value:  void 

//  * . . . . . . . 

void  Admin: : receiveUpdate (  RTI: :ObjectID  theObject, 

const  RTI : : AttributeHandleValuePairSetfc  theAttributes, 

RTI : : FederationTime  theTime , 

const  RTI : :UserSuppl iedTag  theTag. 

RTI : : EventRetractionHandle  theHandle  ) { 

//  find  the  correct  object 

amObject*  tmp  =  Admin: : findSimEntity (theObject) ; 
if  (tmp)  ( 

getMutex ( 1 ->acquire ( ) ; 

tmp->reeeiveUpdates (theObject, theAttributes. theTime, theTag) ; 

getMutex ( ) ->release ( ) ; 

>//  end  if 

//  add  module  if  necessay  or  add  simEntity 
else  C 

cout  «  -Object  “  «  theObject  «  ’  not  found  -  adding-  <<  endl; 

//is  module  loaded 

if  (Admin: : moduleLoaded (theTag) ) ( 

cout  «  "adding  new  *  <<  theTag  <<  endl; 

Admin: : addSimEntity (theTag. theObject) ; 

)//  end  if 

//  if  module  not  loaded 
else  ( 

cout  «  "Loading  Module  '  «  theTag  «  endl; 

Admin: : loadModule (theTag) ; 

Admin: : addSimEntity (theTag,  theObject) ; 

)//  end  else 

)//  end  else 

) / / end  receiveUpdate 


//  Function  Name:  receivelnteraction (  RTI : : InteractionClassHandle 
//  thelnteraction, 

//  const  RTI : : ParameterHandleValuePairSetfc  theParameters, 

//  RTI: : FederationTime  theTime, 

//  const  RTI: :UserSuppl iedTag  theTag, 

//  RTI :: EventRetractionHandle  theHandle 


//  Task:  sends  interaction  data  to  proper  simEntity 

//  Return  Value:  void 

// . * . ****** . * . ******** . **** 

void  Admin: : receivelnteraction {  RTI : :  InteractionClassHandle  thelnteraction, 
const  RTI : : ParamecerHandleValuePairSetfc  theParameters, 

RTI: : FederationTime  theTime, 
const  RTI : :UserSuppliedTag  theTag, 

RTI: : EventRecract ionHand 1 e  theHandle) { 


if (Admin: :ms_InteractionFlag) { 

RTI: :ObjectID  oid  =  0 ; 

if (thelnteraction  ==  ms_CollisionInteractionHandle) { 

RTI : : AttributeHandle  paramHandle; 
unsigned  long  valueLength; 

for  (  unsigned  int  ix  =  0;  ix  <  the  Parameters,  s  ize()  ;  ix**  >( 
paramHandle  =  theParameters. getHandle(  ix  ); 
if  {  paramHandle  ==  ms_EntityIdHandle  ) { 

theParameters .getValue (  ix.  (char* ) &oid,  valueLength  ); 
) / /end  if 
)//end  for 

//  find  the  correct  object 

amObject*  trip  =  Admin:  :  f  indSimEntity  ( (RTI :  :ObjectID)  oid)  ; 
if (trap) ( 

getMutex ( ) ->acquire ( )  ; 

tmp->receiveInteraction( thelnteraction, theParameters) ; 

getMutex ( } ->release ( ) ; 

J / /end  if 
> / / end  if 
else  ( 

cout  «  “Interaction  not  Known  “  «  thelnteraction  «  endl; 
)//end  else 

}//end  if  InteractionFlag 
)//  end  receivelnteraction 


//  . ****** . * . *************** 

//  Function  Name:  sendCollisionlnteraction (RTI : : FederationTime 
//  theTime,  RTI : : Object ID  oid) 

/ t  Task:  sends  Collisioninteraction  data  to  federation 
//  Return  Value:  void 

//  . * . * . . . * . 

void  Admin: : sendCollisionlnteraction (RTI : : FederationTime  theTime, 

RTI: :ObjectID  oid) ( 

RTI :  ; ParameterHandleValuePairSet*  params  =  NULL; 

RTI : :ULong  numparams (1)  ; 

params  =  RTI :: ParameterSetFactory: : create (numparams) ; 


II . * . . . * . ******* . 

//  Function  Name:  removeAmObject (RTI :: Object ID  oid) 

It  Task:  does  house  keeping  required  to  remove  a  simEntity  from  the 
II  federation 
//  Return  Value:  void 

//  ******* . * . * . * . *********** . . 

void  Admin: : removeAmObject (RTI :: Object ID  oid)  { 

amObject*  pBoid  =  NULL; 
unsigned  int  ndx  =  0; 


t(  cheek  if  item  to  be  deleted  is  the  terrain  module 

if  (  Admin: :ms_Terrain  Admin: :ms_Terrain->getEntityID{ )  ==  oid  )( 

if (Admin: :ms_Terrain->localObject () ){ 
getMutex ( ) ->acquire ( > ; 
try  ( 

Admin: :ms_rtiAmb->deleteObject(  Admin: :ms_Terrain->getEntityID ()  , 
0.0,  NULL  ) ; 

}//end  try 

catch (RTI :: Exception  &e) { 
cerr  «  &e  <<  endl; 

}//end  catch 

getMutex ( ) ->release ( )  ; 

)//end  if 

Admin: :ms_Terrain->deleteObject () ; 

Admin : :ms_Terra in  =  NULL; 

) 

else  {  //  not  a  Terrain  entity 

// - - - - - - 

//  Find  the  instance. 

U - - - 

vector<amObject*>: : iterator  ptr; 
amObject*  tmp  =  NULL; 

getMutex ( ) ->acquire ( ) ; 

for  (ptr  =  ms_amObjectArray.begin() ;  ptr  !=  ms_amObjectArray . end ( } ; 
ptr**)  { 

tmp  *  (amObject* ) (*ptr) ; 
if (tmp  (tmp->getEntityID( )  -=  oid)} { 
pBoid  =  tmp; 
break ; 

}/ /end  if 
} / / end  for 


params->add (getEntityldHandle ()  ,  (char*)  oid.  sizeof (RTI: :ObjectID] ) ; 

getMutex ( ) ->acquire ( )  ; 

try( 

Admin: :ms_rtiAmb->sendInc erection (getCollisionlnteractionHandle ( ) , 
•params, theTime, NULL) ; 

) 

catch  (RTI ::  Exceptions:  e)  ( 
cerr  «  s<e  «  endl; 

) 

getMutex ( ) ->release ( )  ; 

)//  end  sendCollisionlnteraction 


//  . ******* . **** 

//  Function  Name:  sendEntityUpdate (RTI : :ObjectID  theObjeet, 

//  RTI ; : AttributeHandleValuePairSeti  theAt tributes. 

//  const  RTI : :UserSuppliedTag  theTag) 

//  Task:  sends  the  handle  value  pair  from  an  entity  to  the  federation 
//  Return  Value:  void 

//  . . . . . 

void  Admin: : sendEntityUpdate (RTI : :0bjectID  theObjeet. 

RTI: :AttributeHandleValuePairSet&  theAt tr ibute s , 
const  RTI :: User SuppliedTag  theTag) ( 

RTI: : FederationTime  theTime  =  m_lastTime  *  ms_grantTime; 

if  (  Admin: :ms_rtiAmb  ) { 

ft . . - . - - - 

II  Update  state  of  Boid 

// . . . . . 

getMutex { ) ->acquire ( )  ; 

try 

C 

Admin: :ms_rtiAmb->updateAttributeValues (  theObjeet, 
theAttributes,  theTime,  theTag  ) ; 

II  Must  free  the  memory 
theAttributes . empty ( ) ; 

) / /end  try 

catch  (  RTI:  : Exceptions,  e  ) 

{ 

cerr  <<  fce  «  endl; 

}//end  catch 

getMutex  ( )  ->release  ( )  ,- 

)/ /end  if 

m_lastTime  =  theTime; 

)//end  send&itityUpdate 


if  {  pBoid  ) ( 

Admin: : ms_NumberAmObjects--; 

// . . - . . . . . - . 

//  If  the  instance  is  a  local  object 
//  we  should  delete  it  from  the  RTI  space. 

// - - - 

if  (  Admin: :ms_rtiAmb  &&  pBoid->localObj ect ( )  )( 
try( 

Admin: :ms_rtiAmb->deleteObject (  pBoid->getEntityID( ) , 
0.0,  NULL  ) ; 

) 

catch  (RTI ::  Exception  S<e!  ( 
cerr  «  &e  «  endl; 

) 

) / /  end  i £ 
else  ( 

II  — . - . . . . . 

ft  Otherwise,  this  is  a  remote  object  that  removeObject  was 
//  called  on. 

// . . — . - . . . — . 

//We  don't  need  to  do  anything  here 
}//end  else 

ras_amObj ect Array .erase (ptr) ; 
pBoid->deleteObject ( ) ; 

}//end  if 

getMutex ( ) ->release ( )  ; 

)//  end  else 
}//end  removeAmObject 


n  . . * . * . . 

//  Function  Name:  removeModule (const  char*  moduleName) 

//  Task:  removes  module  object  form  moduel  array 
//  Return  Value:  void 

//  . . . . . . . . 

void  Admin :: removeModule (const  char*  moduleName) { 
amObject*  tmpObject  =  NULL; 
amObject*  tmp  =  NULL; 
unsigned  int  ndx  =  0; 

// . 

//  Find  the  position  of  this  instance. 

// . - . 

vector<amObject*> :: iterator  ptr; 

getMutex ( ) ->acquire ( ) ; 

for  (ptr  =  ms _ModuleArray. begin () ;  ptr  !=  msJIoduleArray. end ( ) ;  ptr++) ( 
tmp  a  (amObject*) (*ptr) ; 

if  (tmp  S>S<  (strcmp(tmp->getModuleName  ()  .moduleName)  a=0)  )  ( 
tmpObject  =  tmp; 
ms_ModuleArray. erase (ptr) ; 
break; 
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Admin: :ms_NumberModules--; 
delete  tmpObject; 

) //endif 

)//end  remove  Module 


//  Function  Name:  checkEntityCollision (amObject*  that) 

//  Task:  iterates  ObjectArray  looking  for  collisions  with  other 
//  entities 

//  Return  Value:  amObject"  it  collided  with 

//  . . * . * . . . . . * . . . 

amObject*  Admin :: checkEntityCollision (amObject •  that) ( 

amObject*  tmp  =  NULL; 
amObject*  retObj  =  NULL; 

vector<amObject*>: iterator  ptr; 
ptr  =  Admin:  :ms_amOb jectArray . begin  O  ; 

getMutexO  ->acquire( )  ; 


while (ptr  !=  Admin: :ms_amObjectArray.end( )) { 
tmp  =  (amObject*) *ptr; 
if  (tmp  !=  that)  l 

if ( tmp->checkCollision ( that) ) ( 
retObj  =  tmp; 
break; 

> //end  if 
}//end  if 
ptr*+; 

J//end  while 
getMutexO ->release( ) ; 
return  retObj; 

}//end  checkentityCollision 


//  . * . . 

H  Function  Name:  getMutexO 

//  Task:  pointer  to  Admin  class  Mutex 

I l  Return  Value:  ACE_Recursive_Thread_Mutex» 

//  . . * . * . * . 


ti . * . . . . . . . . . 

1 1  EXECUTIVE  SUMMARY 
H 

n  File  Name:  AdminFederateAmbassador . h 
II 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
1/ 

//  Description:  Method  Definitions  of  AdminFederateAmbassador  class 
//  This  file  defines  Federate  ambassador  functions  required  for 
//  proper  execution  in  this  federation 
// 

//  September  1998,  Masters  Thesis 

//  . * . . . * . . . ........ 

•include  "Rti.hh* 

•ifndef  ^AdminFederateAmbassador 
•define  _AdminFederateAmbassador 


class  AdminFederateAmbassador  :  public  RTI : : FederateAmbassador 
( 

public: 

iiiiintiiiimtuuutiitutnnut 

//  Federation  Management  Services  // 

iitmuunuiiuminuitiniim 

II  2.6 

virtual  void  initiatePause  ( 

const  RTI: :PauseLabel  label)  //  supplied  C4 
throw  ( 

RTI:  : FederateAlreadyPaused, 

RTI : ; FederatelnternalError) ; 

//  2.9 

virtual  void  initiateResume  () 
throw  { 

RTI: : FederateNotPaused, 

RTI: : FederatelnternalError) ; 

//  2.12 

virtual  void  initiateFederateSave  ( 

const  RTI : :SaveLabel  label)  //  supplied  C4 
throw  ( 

RTI: :UnableToPer formSave. 

RTI: : Federate Internal Error) ; 

virtual  void  initiateFederateSave  ( 

const  RTI: :SaveLabel  label.  //  supplied  C4 

RTI: :FederationTime  theTime)  //  supplied  Cl 

throw  ( 

RTI: : InvalidFederationTime, 

RTI: :UnableToPer formSave, 

RTI: : FederatelnternalError) ; 

n  2.16 

virtual  void  initiateRestore  ( 

const  RTI: :SaveLabel  label)  //  supplied  C4 


throw  ( 

RTI : : Specif iedSaveLabelDoesNotExist , 

RTI: :CouldNotRestore, 

RTI : : FederatelnternalError) ; 

mmuuiiiiuiuumnniuimii 

II  Declaration  Management  Services  // 
///////////////////////////////////// 

//  3.5 

virtual  void  startUpdates  { 

RTI: :ObjectClassHandle  theClass,  //  supplied  Cl 

const  RTI : : AttributeHandleSeti  theAt tributes)  //  supplied  C4 
throw  ( 

RTI: :ObjectClassNotPublished. 

RTI: : AttributeNotPublished. 

RTI : ; FederatelnternalError) ; 

virtual  void  stopUpdates  { 

RTI: : ObjectClassHandle  theClass,  //  supplied  Cl 

const  RTI: : AttributeHandleSetSc  theAt tr ibut es )  //  supplied  C4 
throw  ( 

RTI: :ObjectClassNotPublished, 

RTI: : AttributeNotPublished. 

RTI: : FederatelnternalError) ; 


virtual  void  startlnteractionGeneration  ( 

RTI : : InteractionClassHandle  theHandle)  II  supplied  Cl 
throw  { 

RTI : : InteractionClassNotPublished , 

RTI : : FederatelnternalError) ; 

virtual  void  stopInteractionGeneration  ( 

RTI :: InteractionClassHandle  theHandle)  //  supplied  Cl 
throw  ( 

RTI : : InteractionClassNotPublished , 

RTI : : FederatelnternalError) ; 

//////////////////////////////// 

//  Object  Management  Services  // 

luiiiuuiiuiniiuiiimuin 

tl  4.4 

virtual  void  discoverObject  { 

RTI: :ObjectID  theObject,  //  supplied  Cl 

RTI: :ObjectClassHandle  theObjectClass ,  //  supplied  Cl 

RTI : : FederationTime  theTime,  //  supplied  Cl 

const  RTI: : User SuppliedTag  theTag,  //  supplied  C4 

RTI : :EventRetractionHandle  theHandle)  //  supplied  Cl 

throw  ( 

RTI: : CouldNotDiscover , 

RTI: : Obj  ectClassNotKnown, 

RTI : : InvalidFederationTime, 

RTI : : FederatelnternalError) ; 

II  4.5 
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virtual  void  ref lectAttributeVa lues  ( 

RTI : : Ob jectID  theObject . 

const  RTI : :  AttributeHandleValuePairSetS.  theAttribut 


RTI: FederationTime 
const  RTI: : UserSuppliedTag 

RTI: : EventRetractionHandle 

throw  ( 

RTI: :Ob jectNotKnown , 

RTI: : AttributeNotKnown, 

RTI : : InvalidFederationTime, 

RTI:  FederatelnternalError)  ; 


Interact ionClassHandle 


theTime, 
theTag , 
theHandle ) 


//  supplied  Cl 
s,  //  supplied  C4 
//  supplied  Cl 
//  supplied  C4 
//  supplied  Cl 


thelnteraction,  //  supplied  Cl 


ParameterHandleValuePairSetS.  theParamete 
FederationTime  theTime, 

UserSuppliedTag  theTag, 

EventRetractionHandle  theHandle) 


Interact ionClassNotKnown, 
InteractionParameterNotKnown. 
InvalidFederationTime. 
FederatelnternalError) ; 


//  4.9 

virtual  void  removeObject  ( 

RTI: :ObjectID  theObject,  //  supplied  Cl 

RTI: :ObjectRemovalReason  theReason,  //  supplied  Cl 

RTI : : FederationTime  theTime,  //  supplied  Cl 

const  RTI :: UserSuppliedTag  theTag,  //  supplied  C4 

RTI: : EventRetractionHandle  theHandle)  //  supplied  Cl 

throw  ( 

RTI : :0b jectNotKnown, 

RTI : : InvalidFederationTime, 

RTI: : FederatelnternalError) ; 


//  supplied  C4 
//  supplied  Cl 
//  supplied  C4 
//  supplied  Cl 


virtual  void  removeObject  ( 

RTI : : Object ID  theObject,  //  supplied  Cl 

RTI : :ObjectRemovalReason  theReason)  //  supplied  Cl 
throw  ( 

RTI: :0b jectNotKnown, 

RTI : : InvalidFederationTime, 

RTI: FederatelnternalError) ; 

//  4.15 

virtual  void  provideAttributeValueUpdate  ( 

RTI: :0bjectID  theObject,  II  supplied  Cl 

const  RTI: AttributeHandleSets.  theAttributes)  / 1  supplied  C4 
throw  ( 

RTI : :ObjeetNotKnown, 

RTI : :AttributeNotKnown, 

RTI : FederatelnternalError) ; 

//  4.17 

virtual  void  ref lectRetraction  ( 

RTI :: EventRetractionHandle  theHandle)  II  supplied  Cl 


throw  ( 

RTI: : EventNotKnown, 

RTI:  FederatelnternalError)  ; 

lUHiniiiiimuuiiinniiinui 

1/  Ownership  Management  Services  // 

iiintuiiiiiiiiiitnniiininiiii 

II  5.2 

virtual  RTI :: AttributeHandleSets  11  return* 

requestAttributeOwnershipAssumption  ( 

RTI : : Object ID  theObject,  //  supplied  Cl 

const  RTI: : AttributeHandleSets.  of feredAt tributes ,  //  supplied  C4 

const  RTI :: UserSuppliedTag  theTag)  //  supplied  C4 

throw  [ 

RTI: :0b jectNotKnown. 

RTI:  :AttributeAlreadyOwned, 

RTI: FederatelnternalError) ; 

virtual  RTI ::  AttributeHandleSets.  //  return? 

request AttributeOwnershipAssumption  ( 

RTI: :0bjeetID  theObject,  //  supplied  Cl 

const  RTI :: AttributeHandleSets.  of feredAttributes )  //  supplied  C4 

throw  { 

RTI: :0b jectNotKnown, 

RTI: : AttributeAlreadyOwned, 

RTI: FederatelnternalError) : 

//  5.3 

virtual  void  attributeOwnershipDivestitureNotif ication  ( 

RTI : : ObjectID  theObject,  ft  supplied  Cl 

const  RTI: : AttributeHandleSets.  releasedAttributes)  //  supplied  C4 
throw  ( 

RTI : : Ob j  ectNotKnown , 

RTI: :AttributeNotKnown, 

RTI: FederatelnternalError) ; 

//  5.4 

virtual  void  attributeOwnershipAcquisitionNotif ication  { 

RTI: :ObjectID  theObject.  //  supplied  Cl 

const  RTI :: AttributeHandleSets.  securedAttributes)  //  supplied  C4 
throw  ( 

RTI : : Ob j  ectNotKnown . 

RTI: : AttributeNotKnown, 

RTI : : FederatelnternalError) ; 

//  5.6 

virtual  RTI ::  AttributeHandleSets.  //  retu: 

requestAttr  ibuteOwnershipRelease  ( 

RTI: :ObjectID  theObject,  //  supplied  Cl 

const  RTI: : AttributeHandleSets.  eandidateAttributes,  //  supplied  C4 
const  RTI :: UserSuppliedTag  theTag)  II  supplied  C4 

throw  { 

RTI : :0b jectNotKnown, 

RTI :  :  AttributeNotKnown, 

RTI : FederatelnternalError) ; 


II  S  .7 

virtual  void  informAttributeOwnership  ( 

RTI : :0b jectID  theObject,  //  supplied  Cl 

RTI: : AttributeHandle  theAttribute,  II  supplied  Cl 
RTI : : FederateHandle  theOwner)  ft  supplied  Cl 

throw  { 

RTI : FederatelnternalError) ; 

inuiiiuiiuinuiiininiu 

//  Time  Management  Services  II 

inniuuiiiiuiiimiuiiiH 
//  6.10 

virtual  void  timeAdvanceCrant  ( 

RTI : FederationTime  theTime)  //  supplied  Cl 
throw  { 

RTI: : InvalidFederationTime, 

RTI : :TimeAdvanceWasNot InProgress, 

RTI : FederationTimeAlreadyPassed, 

RTI: FederatelnternalError) ; 

////////////////////////////////// 

//  Data  Distribution  Management  // 
////////////////////////////////// 

//  7.4 

virtual  void  changeThresholds  { 

RTI::Region  theRegion,  II  supplied 

RTI:  :ThresholdSetSt  theThresholds)  II  returned 
throw  ( 

RTI: :RegionNotKnown, 

RTI: FederatelnternalError) ; 

If  6:17  PM  8/28/96  federateAmbServices.hh  5 


EXECUTIVE  SUMMARY 


File  Name:  AdminFederateAmbassador . C 


Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

Description:  Method  Definitions  of  AdminFederateAmbassador  class 
This  file  defines  Federate  ambassador  functions  required  for 
proper  execution  in  this  federation 

September  1998,  Masters  Thesis 


#include  "AdminFederateAmbassador .h’ 

#include  "Rti.hh" 

#include  "admin. h* 

////////////////////////////////////////////////////////////////////// 
//  AdminFederateAmbassador  Class 

////////////////////////////////////////////////////////////////////// 

////////////////////////////////////////////////////////////////////// 
//  Construction/Destruction 

////////////////////////////////////////////////////////////////////// 


//////////////////////////////////// 

//  Federation  Management  Services  // 

//////////////////////////////////// 

void  AdminFederateAmbassador:  :  initiatepause (  const  RTI :  :  PauseLabel  label  ) 
throw  (RTI : : FederateAlreadyPaused. 

RTI: FederatelnternalError) 


//  Not  implemented  in  1.0 


oid  AdminFederateAmbassador:  :  initiateResume  ( ) 
throw  (RTI:  FederateNotPaused, 

RTI : : FederatelnternalError) 


//  Not  implemented  in  1.0 

) 

void  AdminFederateAmbassador: : initiateFederateSave (  const  RTI : :SaveLabel 
label  ) 

throw  (RTI : :UnableToPerformSave, 

RTI : : FederatelnternalError ) 


U  Not  implemented  in  1.0 
#ifdef  TEST_SAVE 

saveFlag  =  RTI : : RTI_TRUE; 

cerr  «  "initiateFederateSave  called  with  label  -  "  <<  label  «  endl; 
tendi f 
) 
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void  AdminFederateAmbassador; : initiateFederateSave (const  RTI: :SaveLabel 
label, 

RTI; :FederationTime  theTime) 
throw  {RTI : : InvalidFederationTime . 

RTI; : UnableToPerf ormSave, 

RTI: FederatelnternalError) 

{ 

//  Not  implemented  in  1.0 

) 

void  AdminFederateAmbassador: : initiateRestore {const  RTI : : Save Label  label) 


throw  (RTI 
RTI 
RTI 


Spec i f i edSave  Labe 1 Doe  sNot  Ex i s  i 
CouldNotRestore, 
FederatelnternalError ) 


//  Not  implemented  in  1.0 


miinuiiniuumnuumuniu 

//  Declaration  Management  Services  // 

imniiuntinumiinnmitum 

void  AdminFederateAmbassador: : startUpdates  (RTI ;  :0b jectClassHandle  theClass, 

const  RTI: :Attr ibuteHandleSetfc 

theAttributes) 

throw  (RTI: :ObjectClassNotPublished, 

RTI : : At tributeNotPubl ished . 

RTI: ; FederatelnternalError) 

C 

eerr  «  “AFA: : startUpdates*  <<  endl; 

// - 

//  Gets  called  immediately  in  1 . 0  for  all  classes  you  publish. 


Admin : :ms_InteractionFlag  a  RTI : : RTI_TRUE ; 

) 

void  AdminFederateAmbassador ; :stopInteractionGeneration 
(RTI: : InteractionClassHandle  theClass) 
throw  (RTI: : Interact ionClassNotPubl ished, 

RTI: : FederatelnternalError) 

( 

cerr  «  “stopINteractionGeneration*  <<  endl; 

Admin: :ms_InteractionFlag  =  RTI :: RTI_ FALSE; 


nmmmniimuuimmiu 

//  Object  Management  Services  // 

uimunniummnmuiin 

void  AdminFederateAmbassador : idiscoverObject (  RTI: :ObjectID 
theObject, 


theOb j  ectClass , 


RTI: :Ob jectClassHandle 
RTI : : FederationTime 


const  RTI: :UserSuppl iedTag  theTag, 
RTI : :EventRetractionHandle 


theHandle) 

throw  (RTI: : CouldNotDiscover, 

RTI: :0b j  ectClass Not Known, 

RTI: : InvalidFederationTime, 

RTI: : FederatelnternalError) 

( 

cout  «  "AFA: discovered  object  *  «  theObject  • 


’  Module  “  <<  theTag  • 


void  AdminFederateAmbassador: :stopUpdates  (RTI: :0b jectClassHandle  theClass. 

const  RTI: : AttributeHandleSetfc 

theAttributes) 

throw  (RTI: :Obj ectClassNotPublished, 

RTI: :AttributeNotPubl ished, 

RTI : : FederatelnternalError) 
t 

cerr  «  “stopUpdates"  «  endl; 

//  Never  gets  called  in  1.0  but  we  will  implement  it  for  good  form. 


-id  AdminFederateAmbassador: : startlnteraetionGeneration 
(RTI: : InteractionClassHandle  theClass) 
throw  (RTI: : InteractionClassNotPublished, 

RTI : : FederatelnternalError) 


//is  this  an  object  type  I  know  about 

if  ( theOb  j  ectClass  ==  Admin-.  :  getESClassHandle  ( )  )  ( 

//is  module  loaded 

if  (Admin : :moduleLoaded (theTag) ) ( 

Admin: :addSimEntity (theTag, theObject) ; 

)//  end  if 

//  if  module  not  loaded 
else  { 

Admin: : loadModule (theTag) ; 

Admin: : addSimEntity ( theTag ,  theObject) ; 

)//  end  else 

)//  endif 
else  { 


“Discovered  Obect  cl a: 


:  unknown  to  me.“  «  endl; 


cerr  «  “startInteractionGenerati< 


)//  end  discover  object 

void  AdminFederateAmbassador: :reflectAttributeValues 

(  RTI: :ObjectID  theObject, 

const  RTI : : AttributeHandleValuePairSetfc  theAttributes, 

RTI: : FederationTime  theTime, 

const  RTI :  :  CJserSuppl  iedTag  theTag, 

RTI: : BventRecractionHandle  theHandle  ) 

throw  (RTI : :0bjectNot Known, 

RTI : : Attr ibuteNotKnown, 

RTI: : InvalidFederationTime, 

RTI : : FederatelnternalError  > 

1  Admin:  :receiveUpdate( theObject,  theAttributes,  theTime,  theTag, theHandle)  ; 

)//  end  ref lectAttributeVa lues 

void  AdminFederateAmbassador: : receivelnteraction 

{  RTI :: InteractionClassHandle  thelnteraction, 

const  RTI : : ParameterHandleValuePairSetfc  theParameters, 

RTI: : FederationTime  theTime, 
const  RTI : :UserSuppl iedTag  theTag, 

RTI: :EventRetractionHandle  theHandle) 
throw  (RTI : : InteractionClassNotKnown , 

RTI : : Interact ionParameterNotKnown, 

RTI ; : InvalidFederationTime, 

RTI: : FederatelnternalError) 


RTI: : InvalidFederationTime, 
RTI: : FederatelnternalError) 


: receivelnteraction ( thelnteracti 


leters, theTime, theTag, theHand 


void  AdminFederateAmbassador: :remove0bject (  RTI : :ObjectID 
theObject, 

RTI: ;0bjectRemovalReason 

theReason. 

RTI : : FederationTime  theTime, 

const  RTI: : UserSuppl iedTag  theTag, 
RTI : : EventRetractionHandle  theHandle 

) 

throw  (RTI : :ObjectNotKnown, 

RTI : : InvalidFederationTime, 

RTI: FederatelnternalError) 

{ 

//  Call  the  other  removeOb j ect  method  since  this  should  probably 
//  be  implemented  using  default  parameter  values. 


removeObject (theObject, theReason) ; 


cout  «  “AFA: : removeOb j ect*  <<  endl; 
Admin: :retnoveAmObject (theObject) ; 


■old  AdminFederateAmbassador:  :provideAttributeValue(Jpdate 
l  RTI: :ObjeetID  theObject. 

const  RTI :: Attr ibuteHandleSetfc  theAttributes) 
throw  (RTI : :0b jectNot Known. 

RTI: : AttributeNotXnown. 

RTI : : FederatelnternalError) 


void  AdminFederateAmbassador: :reflectRetraction (  RTI:  : EventRetractionHandle 
theHandle  ) 

throw  ( RTI : : EventNotKnown , 

RTI: FederatelnternalError) 

cerr  «  “AdminFederateAmbassador :: ref lectRetraction:  handle  =  "  «  endl; 
//  I  didn't  implement  this  one  -  sorry! 

> 

/////////////////////////////////// 

//  Ownership  Management  Services  // 

/////////////////////////////////// 

RTI: :AttributeHandleSetfc 

AdminFederateAmbassador : :requestAttributeOwnershipAssumption 
(  RTI: :ObjectID  theObject, 

const  RTI : : AttributeHandleSetfc  of feredAttributes , 
const  RTI : :UserSuppliedTag  theTag) 

throw  (RTI : :ObjectNotKnown, 

RTI : :AttributeAlreadyOwned. 

RTI: FederatelnternalError) 

( 

//  I  didn’t  implement  this  one  -  sorry! 

//  The  following  is  to  allow  it  to  compile  with  the  SparcWorks  compiler 
RTI : :AttributeHandleSet*  dummy  = 

RTI: : At tributeHandleSet Factory: : create (0) ; 
return  “dummy; 


RTI :: AttributeHandleSetfc 

AdminFederateAmbassador : : requestAttributeOwner shipAssumption 
{  RTI: :0bjectID  theObject, 

const  RTI :: AttributeHandleSetfc  of feredAttributes  ) 


•oid  AdminFederateAmbassador :: removeObject (  RTI : lObjeetlD  theObject, 

RTI: :ObjectRemovalReason  theReason) 

throw  (RTI : :ObjectNotKnown, 


throw  (RTI: :0bjectNotKnown, 

RTI: : At  t  r ibut  eAlreadyOwned , 
RTI: FederatelnternalError) 
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//  I  didn’t  implement  this  < 


■  sorry! 


//  The  following  is  to  allow  it  to  compile  with  the  SparcWorks  compiler 
RTI : : AttributeHandleSet  *  dmrony  = 

RTI : : AttributeHandleSetFactory : : create (0) ; 
return  *  dummy 

} 

void  AdminFederateAmbassador :  : attributeOwnershipDivestitureKotif icat ion 
{  RTI: : Object ID  theObject, 

const  RTI :: AttributeHandleSet*.  releasedAttributes) 
throw  (P.TI :  :ObjectNotKnown. 

RTI : :AttributeNotKnown. 

RTI : FederatelnternalError) 

{ 

//  I  didn’t  implement  this  one  -  sorry! 

> 

void  AdminFederateAmbassador : : attributeOwnershipAcquisitionNotif ication 
(  RTI: : Object ID  theObject, 

const  RTI : :AttributeHandleSetS.  seeuredAttr ibutes  } 
throw  {RTI: :Obj ectNotKnown, 

RTI: :AttributeNotKnown, 

RTI : : FederatelnternalError ) 

{ 

//  I  didn’t  implement  this  one  -  sorry! 

> 

RTI : : AttributeHandleSet*. 

AdminFederateAmbassador: : requestAttributeOwnershipRelease 
(  RTI: :ObjectID  theObject, 

const  RTI : :AttributeHandleSetSi  candidateAttr ibutes, 
const  RTI : :UserSuppliedTag  theTag  ) 
throw  [RTI : :Obj ectNotKnown, 

RTI : :AttributeNotKnown, 

RTI: : FederatelnternalError) 

( 

//I  didn’t  implement  this  one  -  sorry! 

//  The  following  is  to  allow  it  to  compile  with  the  SparcWorks  compiler 
RTI :: AttributeHandleSet*  dummy  = 

RTI: : At tributeHandleSet  Factory : :create{0) ; 
return  ‘dummy; 

) 

void  AdminFederateAmbassador: :informAttributeOwnership 
{  RTI: : Object ID  theObject, 

RTI: : AttributeHandle  theArtribute, 

RTI: : FederateHandle  theOwner) 
throw  (RTI : : FederatelnternalError) 


//  I  didn't  implement  this  one  -  sorry! 


////////////////////////////// 
//  Time  Management  Services  // 


//  . . * . ************* . ***** . *•** 

void  setVelocity (npsVec3f ) ; 

//  EXECUTIVE  SUMMARY 

void  setAmmunition(int) ; 

II 

void  setDamage ( float) ; 

II  File  Name:  amObject.h 

II 

//  RTI  ambassdor  interface 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

II 

//  Description:  pure  virtual  class  defining  the  interface  between 

virtual  void  sendUpdates (RTI : : FederationTime  theTime)  =  0; 

virtual  void  sendUpdates (RTI : : Ob j ectID. RTI: : AttributeHandleValuePairSett , 

//  adminModule  objects,  the  federate  Ambassador  and  rti  ambassador 

II 

//  September  1998.  Masters  Thesis 

RTI : FederationTime ,  RTI : :UserSuppliedTag)  =  0; 

//  . ***** . * . * . 

virtual  void  sendlnteraction (RTI : : InteractionClassHandle, 

•  include  "npsQuatemion .  h‘ 

RTI:  :  Parame t erKandl eVa  1  uePairSe t £. ,  RTI :  FederationTime, 

•include  *npsVec3f .h” 

RTI: :UserSuppliedTag)  =  0; 

•include  "Rti.hh" 

•include  "ace/OS.h" 

//  FederateAmbassador  interface 

•ifndef  amObject 

virtual  void  receiveUpdates (RTI: :ObjectID  oid, 
const  RTI : : AttributeHandleValuePairSetfc  ta. 

•define  _amObject 

RTI: FederationTime  ft,  RTI: :UserSuppliedTag  tag)  =  0; 

•ifndef  SIM.API 

virtual  void  receivelnteraction (RTI :: InteractionClassHandle, 

•if def  VISUALCPP 

RTI:  :  ParameterHandleValuePairSetfc,  RTI:  .-FederationTime, 

•define  SIM_API  _ declspec (dllimport ) 

RTI: :UserSuppliedTag)  =  0; 

•  else 

•define  SIM  API 

virtual  void  receivelnteraction (RTI :: InteractionClassHandle, 

•endif 

const  RTI : : ParameterHandleValuePairSetfc)  =  0; 

•endif 

class  amObject 

//  Object  display 

virtual  void  displayO  =  0; 

{ 

public: 

virtual  amObject*  createObj ect (RTI : :ObjectID>  a  0; 

//  member  variables 

RTI: :ObjectID  entitylD; 

virtual  void  deleteObj ect ( )  =  0; 

npsVeclf  position; 

npsQuatemion  orientation; 

virtual  char*  getModuleName ( )  =  0; 

npsVec3f  velocity; 

int  ammunition; 

virtual  RTI:: Boolean  localObject (}  =  0; 

float  damage; 

virtual  RTI:: Boolean  checkCollision (amObject*  that)  =  0; 

amObject (RTI : :ObjeetID) ; 

amObject ( ) ; 

virtual  float  checkTerrainCollision (amObject*  that)=  0; 

//getters  of  Entity  State  fields 

virtual  RTI::  Boolean  isTerrainO  =0; 

RTI : :Obj  ectID  getEntityID{ ) ; 

);  //  end  amObject 

npsVec3f  getPosition{ ) ; 

npsQuatemion  getOrientation  ( )  ; 

•endif 

npsVec3  f  getVelocity ( ) ; 

int  getAmmunition {) ; 

float  get Damage ( } ; 

U setters  of  Entity  State  fields 

void  setEnt itylD (RTI :: Ob j ectID) ; 

void  setPosition(npsVec3f) ; 

void  setOrientation  (npsQuatemion) ; 
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ninittiiintinitiniiiinii 

void  AdminFederateAmbassador : :timeAdvanceCrant {  RTI: ;FederationTime  theTime  ) 
throw  (RTI: : InvalidFederationTime, 

RTI : : TimeAdvanceWasNot InPr ogres s , 

RTI : : FederationTimeAlreadyPassed, 

RTI: FederatelnternalError) 

{ 


// - 

//  Set  the  time  granted  ! 
//  time  has  changed. 


i  and  the  flag  to  let  me  know 


//  Admin: :ms_grantTime  =  theTime; 

II  Admin : : ms_t imeAdvGr ant  =  RTI : : RTI_TRUE ; 


/////////////////////////////////////////////////////////// 

//  Data  Distribution  Management  -  NOT  IMPLEMENTED  IN  1.0// 
/////////////////////////////////////////////////////////// 

void  AdminFederateAmbassador :: changeThresholds (  RTI::Region  theRegion, 

RTI :  :ThresholdSet*.  theThresholds 

) 

throw  (RTI : : RegionNotKnown. 

RTI: FederatelnternalError) 

( 

//  Not  implemented  in  1.0 

) 


//  EXECUTIVE  SUMMARY 
// 

If  File  Name:  amObject.  c 
ft 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

If  Description:  Defines  the  base  object  that  must  be  inherited  by  all 
//  participating  in  the  federation 
// 

//  September  1998,  Masters  Thesis 

//  . . . * . . . * . ***** 


amBoid  Files 


•include  “amObject. h* 

amObject: :amObject (RTI: : Object ID  oid)  ( 
entitylD  =  oid; 

)//  end  amObject 
amObject: :amObject(> {) 


//getters  of  Entity  State  fields 


RTI:: Object ID 

npsVec3f 

npsQuaternion 

npsVec3  f 

int 

float 


amObject: :getEntityID() {  return  entitylD;} 
amObject: :getPosition ( ) (return  position;) 
amObject: :getOrientation ( ) (return  orientation;} 
amObject: igetVelocity ( ) (return  velocity;} 
amObject: :getAmmunition ( ) (return  ammunition;} 
amObject: :getDamage () (return  damage;} 


//setters  of  Entity  State  fields 

void  amObject: : setEntitylD [ RTI : : Ob jectID  oid} (entitylD  =  oid;} 

void  amObject: :setPosition !npsVec3f  number) (position  =  number;) 

void  amObject : : setOrientation (npsQuaternion  number) (orientation  =  number;} 

void  amObject: :setVelocity(npsVec3f  number) (velocity  =  number;} 

void  amObject: : setAmmunition { int  number) (ammunition  =  number;} 

void  amOb j eet :: setDamage ( float  number) (damage  =  number;) 


EXECUTIVE  SUMMARY 
Pile  Name:  module .h 

Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

Description:  defines  methods  pertinent  to  module  loading  and  unloading 
September  1998,  Masters  Thesis 


•ifndef  _ module 

•define  _ module 


// . . . ****’ 

//  INCLUDES  AND  EXTERNS 

//  . . . 


// . ***’ 

//  DEFINES 
ft . ****' 


//  . . . ******* 

//  FUNCTION  PROTOTYPE  SPECIFICATIONS 

//  ****** . * . * . . 


•ifdef  _ cplusplus 

extern  *C*  ( 

•endif 

ADMIN_API  const  char  *getModuleName ( ) ; 
ADMIN_API  float  getModul eVersion ()  ; 
ADMIN_API  const  char  *getModuleDate { )  ; 
ADMIN_API  const  char  *getModuleText {)  ; 
ADMIN_API  bool  initModule ( ) ; 

ADMIN_API  bool  exitModuleO  ; 

•ifdef  _ cplusplus 

}  ; 

•endif 


This  is  the  module.txt  for  the  amBoid  module 


Bamboo 1 . Ob 


npsVisualModule 
bbK  ey  b  o  a  r  dM  odu  1  e 
npsFlyingCameraModule 
amHLAAdmin 
amCheckerboard 


//  . ****** . . 

//  INLINED  MEMBER  FUNCTIONS 
//  . . . . . . 


•endif  //  _ module 


//  . ***** . . . * . * 

/ /  EXECUTIVE  SUMMARY 
II 

II  File  Name:  module. c 
II 

II  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 
// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
// 

//  September  1998.  Masters  Thesis 

//  . * . * . . 

//  . ********** . * . ************ 

//  INCLUDES  AND  EXTERNS 

//  . *** . * . . 

•include  <stdio.h> 

•include  <stdlib.h>  //  atof 
•include  “module. h* 

•include  “amBoid.h" 

//  ***** . . . * . * . **** . **************** 

//  CODE 

//  . * . ****** . * . 

const  char  *getModuleName ! ) 

{ 

return  “amBoid*,- 

} 

float  getModuleVersionO 

{ 

return  1.0; 

) 

const  char  ‘getModuleDate O 

{ 

return  *1998/09/01  06:05:48*; 


//  . . . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  amBoid.h 
// 

//  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 
/  / 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 

// 

//  September  1998,  Masters  Thesis 

//  ***** . * . ******** . * . . . 


•ifndef  _amBoid 
•define  _amBoid 


//  . . 

//  INCLUDES  AND  EXTERNS 
//  . . ******* . . 

// . . . . 

//  DEFINES 

//  . . . 


//  . ******** . * . 

//  FUNCTION  PROTOTYPE  SPECIFICATIONS 

//  * . * . . 


void  initamBoidO  ; 
void  exitamBoid( J ; 


//  * . . 

//  INLINED  MEMBER  FUNCTIONS 

//  . . - 


const  char  *getModuleText O 

( 

return  ‘This  is  a  really  nice  module*; 

) 

bool  initModulel) 

{ 

initamBoidO  ; 
return  1; 

) 


•endif  // 


bool  exitModuleO 

{ 

exitamBoid{ ) ; 
return  1; 

} 


// 
II 
II 
II 
// 
// 
II 
1 1 
// 
II 
II 


EXECUTIVE  SUMMARY 
File  Name:  amBoid.h 

Author;  CPT  Stewart  Liles,  Naval  Postgraduate  School 

Description:  defines  methods  pertinent  to  module  loading  and  unloading 
September  1998.  Masters  Thesis 


// 

II 

// 

// 

// 

// 

II 

ft 

II 

// 

// 


EXECUTIVE  SUMMARY 
File  Name:  amBoid.e 

Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

Description:  defines  methods  pertinent  to  module  loading  and  unloading 
September  1998,  Masters  Thesis 


•ifndef  _amBoid 
•define  _amBoid 


//  . . 

//  INCLUDES  AND  EXTERNS 
//  ****** . ********* 

//  . . 

II  DEFINES 

//  . . 


//  * . * . ***** . . 

//  FUNCTION  PROTOTYPE  SPECIFICATIONS 

//  . * . . 


void  initamBoidO  ; 
void  exitamBoidO; 


//  . * . 

//  INLINED  MEMBER  FUNCTIONS 

//  . 


•endif  // 


//  ****** 
II 

It . - 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 


INCLUDES  AND  EXTERNS 


“Rti.hh* 

•amBoid.h* 
“npsVisual .h* 
•npsWindow.h* 
’npsViewport .h“ 
“npsFlyingCamera .h* 
"bbMouse.h* 
•bbScreen.h* 
“bbKeyboard.h" 

“ bbEventResponse . h* 
•bbCallback.h* 
"npsGeometry . h“ 
"boid.h* 

* amHLAAdmin . h * 
•admin. h* 
•amObjeet.h* 
<math.h> 

<GL/gl.h> 


•if def  SGI 

•include  ‘bbSGI.h* 
•endi f 


//  ******* . 

//  CODE 

//  * . . 


Boid  “myBoid;  //  global  local  object 


//function  prototype 
int  mouselnWindow { ) ; 


//  *********** . . . . 

//  Function  Name:  initamBoidO 

//  Task:  initialize  Module  --  this  is  run  only  once 
//  Return  Value:  void 

//  . * . * . ********** . ***** 

void  initamBoidO  { 

void  initXeyboardModule O ; 
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void  ini tVi sua IModu 1  e  0  ; 


wyBoid  =  new  8oid(); 

Admin : :addModuleFunetionPointer (myBoid) ; 


initKeyboardModule ( ) ; 


cout  <<  ‘amBoid  Module  loaded*  <<  endl; 
}//  end  initanBoid 


//  remove  remote  amObjects 

amObject*  theObject  =  Admin::findSimEntity(*amBoid‘); 
while (theObject) { 

Admin: :removeAmObject(eheObject->getEntityID(} ) ; 
theObject  =  Admin : : f indSimEntity ( *amBoid* ) ; 


//  remove  the  module  from  module  list 
Admin; : removeModule ("amBoid") ; 


}//end  exitamBoid 


//  Function  Name:  exitamBoid () 

//  Task:  does  housekeeping  required  ( 
//  this  is  run  only  once 
II  Return  Value:  void 


bbCal IbackHandler  *  ca 1 lba  c kHa nd 1 er ; 
uint  numCallbacks; 

uint  currCal lback; 

bbCallback  ‘callback; 

uint  currDuck; 

npsGeometry  ‘duck; 

bbKeyboard*  keyboard; 

bbEventResponse*  eventResponse; 


//  remove  keyboard  callbacks 
//  RESET 

eventResponse  =  bbEventResponse :: f indob j ect { *amBoidER_Reset ‘ } ; 
callback  =  bbCallback: : f indObject ( “amBoidReset* ) ; 
event Response->removeCal lback (callback) ; 

delete  callback; 


//  remove  keyboard  callbacks 
//  LoadBoid 

eventResponse  =  bbEventResponse: : f indObject ( ‘amBoidER_LoadBoid‘ ) ; 
callback  =  bbCallback: : f indObject (‘amBoidLoa dBo id* > ; 
eventResponse- >removeCal lback (callback)  ; 
delete  callback; 


//  first  remove  update  callback 
callback  =  npsVisual: :appCallbaek( ) ; 

cal IbackHandler  =  callback->getPreCallbackHandler () ; 
callback  =  bbCallback; : f indObject ( 'BoidPreApp* ) ; 
if (callback) { 

ca 1 lba  ckHand ler- >  removeCa 1 lba  ek ( ca llback ) ; 
delete  callback; 

}//end  if 


//  Function  Name:  initKeyboardModule ( > 
//  Task:  add  keyboard  callbacks 
II  Return  Value:  void 


void  initKeyboardModule ()  { 

void  escFunc (bbOb ject  ‘object,  bbData  ‘data); 
void  resetFunc (bbObject  ‘object.  bbData  ‘data) ; 
void  loadBoid (bbObj ect  ‘object,  bbData  ‘data); 


bbKeyboard 

bbEventResponse 

bbCallback 


• keyboard ; 

‘eventRespon: 

•callback; 


II  get  Che  keyboard  device 
keyboard  =  bbKeyboard: :getlnstance () ; 

//  set  up  reset  key 

eventResponse  =  new  bbEventResponse (bbKeyboard: :KEY_SPACE) ; 

eventResponse ->setName { *amBoidER_Reset  * ) ; 

callback  =  new  bbCallback () ; 

cal lback ->setFunc (resetFunc) ; 

callback->setName ( ‘amBoidReset* ) ; 

eventResponse->addCallbackLast (callback) ; 

keyboard ->add EventResponse (eventResponse) ; 

//  sec  up  load  boid  key 

eventResponse  =  new  bbEventResponse (bbKeyboard :: KEY_B  | 
bbKeyboard: :DOWN_TRANS) ; 

eventResponse ->setName [ *amBoidER_LoadBoid" ) ; 
callback  =  new  bbCallback () ; 
cal lback- >setFunc (loadBoid) ; 
callback->setName [ “amBoidLoadBoid*  > ; 
eventResponse- >addCal IbackLast (callback) ; 
keyboard->addEventResponse (eventResponse) ; 


) / / end  initKeyboardModule 


//  Function  Name:  initVisualModule U 

//  Task:  attache  callback  to  PreApp  callback  handler  in  Visula  Module 
//  Return  Value:  void 


void  initCheckerboardFunc (bbObj ect  ‘object.  bbData  ‘data) ; 
void  preAppFunc (bbObject  ‘object,  bbData  ‘data); 


•window; 

•viewport; 

•camera ; 

•eventResponse; 

•callbackHandle: 

•callback; 


npsWindow 

npsVi export 

npsCamera 

bbEventResponse 

bbCallbackHandle: 

bbCallback 

npsVec3f 

nps  Qu  a  t  em  i  on 

npsGeometry 


//  pre  app  callback 

callback  =  npsVisual : :appCa llback () ; 

cal IbackHandler  =  callback->getPreCallbackHandler O ; 

callback  =  new  bbCal lback 0 ; 

callback->setName ( ‘BoidPreApp* ) ; 

ca 1 lba ck->setFunc (preAppFunc) ; 

cal lbackHandler->addCal IbackLast (callback) ; 


)  II  end  initVisualModule 


//  Function  Name:  preAppFunc (bbObject  ‘object.  bbData  ‘data) 
//  Task:  defines  preApp  callback  function  -- 
//  uses  keyboard  controls  to  maneuver  Boid 

//  checks  for  collisions 

//  Return  Value:  void 


void  preAppFunc (bbObj ect  ‘object,  bbData  ‘data)  ( 


void  deleteMyBoid { ) 

float  e 

bbKeyboard  *k 

npsCamera  *  c 

npsVec3f 

npsQuaternion 

npsVec3f 

float 

float  v 


cosh,  sinh,  cosp.  sinp,  cosr,  sznr; 


rotation; 
tmpVec ; 
hpr [  3  J  ; 
elocity  =  0; 


kd  =  bbKeyboard: : get Inst ance( ) ; 

camera  =  npsCamera :: f indObject ( “AdminCamera" ) ; 


//don't  do  anything  unless  there  is  a  local  boid  to  control 
if (myBoid) { 

position  =  myBoid->getPosition ( ) ; 
rotation  =  rayBoid->getOrientationO ; 
rotation.getEulers (hpr) j 

//  Need  this  to  control  each  window  separtely 
//  key  commands  won't  work  unless  the  mouse  pointer 
//  is  in  the  window 


if  (mouselnWindow () > { 

//  update  rotation 

if  (  kd->getVal (bbKeyboard: : KEY_LEFTARROW)  )  (  //  heading  left? 

hpr ( 0 )  «  NPS_DEG2RAD(4.0f> ; 
if  (hpr 101  >  NPS_PI) 

hpr 10 ]  -=  2 . 0  f  *NPS_PI ; 

1 

if  (  kd->getVal (bbKeyboard: :KEY_RIGHTARROW)  )  {  //  heading  right? 

hpr(0]  -=  NPS_DEG2RAD ( 4 . 0 f ) ; 
if  (hpr (0)  <  -NPS_PI) 

hpr (0]  >=  2.0f‘NPS_PI; 

> 

if  {  kd->getVal {bbKeyboard: :KEY_UPARROW)  ){  //  pitching  up? 

hpr  [  1 )  *=  NPS_DEG2RAD ( 4 , 0  f ) ; 
if  (hpr (1)  >  NPS_PI*0.495f) 
hpr [ 1 )  =  NPS_PI‘0.49Sf; 

} 

if  (  kd->getVal (bbKeyboard: :KEY_DOWNARROW)  )(  //  pitching  down? 

hpr  [  1 ]  -=  NPS_DEG2 RAD ( 4 . 0  f ) ; 
if  (hpr (1)  <  -NPS_PI*0.495f) 
hpr [ 1 ]  =  -NPS_PI* 0.495 f; 


rotation. setEulers (hpr) ;  //  set  quaternion 


//  update  velocity 

if  {  kd->getVal (bbKeyboard : :KEY_S)  fct  kd->getVal (bbKeyboard: : KEY_A) 
)  //  dead  stop 

velocity  =  0 . Of ; 

else  if  (  kd->getVal (bbKeyboard: :K£Y_S)  )  //  accelerate 

velocity  -»=  1.2£; 

else  if  (  kd->getVal (bbKeyboard: :KEY_A)  )  U  decelerate 
velocity  -=  1.2f; 

else  {  //  slow  down 

if  (velocity  >=  O.lf) 
velocity  -=  O.lf; 
else  if  (velocity  <-  -O.lf) 
velocity  +=  O.lf; 
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else 

velocity  =  O.Of; 

> 

if  {velocity  >=  2. Of)  //  clamp  velocity  -2  <=  velocity  <= 

velocity  -  2. Of; 
else  if  (velocity  <=  -2. Of) 
velocity  =  -2. Of; 


>//  end  if  mouselnwindow 

It  update  position 

static  RTI :  .-Object ID  oid  =  0; 

old  -  0; 

//  entity  collision 

oid  =  myBoid->hasCollided ( ) ; 

float  yPos  =  0.0; 

RTI::Boolean  terrainFeatureCollision  =  RTI : : RTI_FALSE ; 

//  check  collision  with  terrain 
if {Admin: :ms_Terrain) { 

yPos  =  Admin: :ms_Terrain->checkTerrainCollision(myBoid) ; 
terrainFeatureCollision  =  Admin: :ms_Terrain->checkCollision (myBoid) ; 


//  terrain  is  returning  a  y  Position 
if (yPos  !=  0.0) { 

tmpVec.set (0 .Of .  O.Of.  -l.Of);  U  forward 

tmpVec .scale (velocity) ; 

rotation. xform (tmpVec) ; 

position. add (tmpVec) ;  II  set  vec3f 

position. set(l.yPos) ; 


myBoid->setOrientation (rotation) ; 
camera->setPosition (position) ; 
camera->setOrientation (rotation) ; 


ft  boid  no  collision 
else  if (oid  ==  0) ( 

tmpVec.set (0 .Of,  O.Of,  -l.Of);  //  forward 

tmpVec. scale (velocity) ; 

rotation .xform (tmpVec) ; 

position. add (tmpVec) ;  H  set  vec3f 

myBoid->setVelocity{ tmpVec) ; 
myBoid->setPosition (position) ; 
myBoid->setOr ientation (rotation) ; 
camera->setPosition (position) ; 
camera->setOrientation (rotation) ; 

)//end  else  if 

//  boid  collided  with  entity 
elsef 

tmpVec.set (O.Of,  O.Of.  -l.Of);  II  forward 

tmpVec. scale (velocity) ; 

rotation. xform (tmpVec) ; 

pos it ion. sub ( tmpVec ) ;  //  set  vec3f 

posit  ion. sub (tmpVec) ; 

myBoid->setVelocity (tmpVec) ; 
myBoid- ?-setPosition  (position)  ; 
myBoid->setOrientation (rotation) ; 
camera->setPosition (position) ; 
camera->setOrientation (rotation) ; 

cout  «  “Collided  with  entity  *  «  oid  «  endl; 


myBoid->setVelocity{ tmpVec) ; 
myBoid->setPosition(position) ; 
myBoid-s>setOrientation  [rotation)  ; 
camera->setPosition (position) ; 
camera->setOrientation (rotation) ; 

)//end  if 

//  boid  collided  with  terrain  feature 
else  if (terrainFeatureCollision) { 

tmpVec. set ( myBoid- >getVelocity() ) ;  //  forward 

//  tmpVec . scale (velocity) ; 
rotation. xform (tmpVec) ; 
position . sub (tmpVec) ;  II  set  vec3f 
position. sub (tmpVec) ; 
position. sub(tmpVec) ;  II  set  vec3f 
position. sub (tmpVec)  ; 
position. sub(tmpVec) ;  //  set  vec3f 


RTI : : FederationTime  cheTime  =  0.0; 
myBoid->sendCollisionInteraction (theTime, oid) ; 
)//end  else 

//  check  if  Boid  is  destroyed  in  some  way 
if  (myBoid->getDamage  ( )  -e  0)  ( 
deleteMyBoid( )  ; 

) 

)ll  end  if  myBoid 
) / /  end  preAppFunc 


n  . . ******* . ***** . . 

II  Function  Name:  resetFunc (bbObject  ‘object,  bbData  “data) 

//  Task:  function  defined  for  the  resetBoid  keyboard  callback 
//  Return  Value:  void 

. . * . * . 


myBoid->setVelocity (tmpVec) ; 
myBoid->setPosition (position) ; 


void  resetFunc (bbObject  “object,  bbData  “data) { 


npsCamera* 

npsVec3f 

npsOuaternion 


camera ; 

initPosition; 

initRotation; 


bbScreen: : normal ireVal ( tx. fcy) ; 

if  (viewport- >getWindow() ->isVal!nside (x,y) ) 
flag  =1; 


if  (mouselnWindowO  &&  myBoid)  { 

initPosition. set (0 .Of ,  3. Of.  -lO.Of); 

initRotation . setEulers ( NPS_DEG2  RAD [180. Of). O.Of. O.Of); 


) 

return  flag; 
}//end  mouselnwindow 


{ 


myBoid->setPosition( initPosition) ; 
myBoid->setOr ientation (initRotation) ; 
)//  end  if 
)  //  end  resetFunc 


void  del eteKy Boid ( )  { 

bbCallbackHandler  “callbackHandler ; 

bbCallback  “callback; 


//  . . . 

//  Function  Name:  loadBoid (bbObject  “object,  bbData  “data) 

II  Task:  function  defined  for  the  loadBoid  keyboard  callback 
//  Return  Value:  void 
//  . . . . 


Admin: : removeAmOb ject (myBoid->getEntityID ( ) ) ; 
myBoid  =  NULL; 


}//end  deleteMyBoid 


void  loadBoid (bbObject  “object,  bbData  *data){ 


void  initVisualModule ()  ; 

if  (mouselnWindow ( ) ) ( 

cout  «  "loadBoid*  «  endl; 
if ( (myBoid) { 

initVisualModule( ) ; 

RTI: :0bjectID  oid  =  Admin: :registerOb ject () ; 
amObject*  tmp  = 

Admin: :addSimEntity( "amBoid" ,  oid); 
myBoid  =  (Boid* ) tmp; 

myBoid->setLoca 10b ject (RTI ; :RTI_TRUE) ; 

)//end  if 
)//end  if 
)//  end  loadBoid 


//  . . * . * . . 

//  Function  Name:  mouselnWindowf ) 

II  Task:  tells  if  mouse  is  in  the  correct  window  to  receive  keyboard 
//  commands 

II  Return  Value:  int  representing  boolean 

//  . . * . . . . . . 

int  mouselnWindowO  £ 
int  flag  =  0; 

npsWindow  “window; 

npsViewport  “viewport; 

window  =  npsWindow:  : f indOb ject (“AdminWindow* ) ; 

viewport  =  npsViewport : : f indOb j  ect ( "AdminViewport  * ) ; 

float  x.y; 

X  =  bbMouse :  :getX ( ) ; 
y  =  bbMouse: :getY() ; 
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// . . . ****** . . . . . 

//  EXECUTIVE  SUMMARY 
II 

//  File  Name:  Boid.h 
// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

n 

//  Description:  defines  boid  class 
// 

//  September  1998,  Masters  Thesis 
//  . . . . * . . 


Static  RTI : rBoolean 
static  RTI : :Boolean 
static  RTI:;Boolean 


ms_sendRotationUpdates ; 
ms_sendPositionUpdates; 
Bis_sendCommInteractions , 


//  member  functions 
public: 

Boid { ) ; 

Boid{  RTI: :ObjectID  id); 

void  setLocalObject (RTI : :8oolean) ; 

RTI: :ObjectID  hasCollided ( ) ; 


virtual  -Boid(); 


•include  'Rti.hh' 
•include  *npsVec3f.h* 
•include  ‘npsGeometry.h* 
•include  'bbKeyboard.h' 
•include  'amObject.h' 
•include  'admin. h’ 


virtual  void  display!); 

virtual  amObject*  createObject ( RTI : :ObjectID  oid) ; 
virtual  void  deleteObject ( ) ; 


•ifndef  ADMIN_API 
•ifdef  VISUALCPP 

•define  ADMIN.API  declspec (dll import) 

•else 

•define  ADM I N_ API 
•endif 
•endi f 


virtual  char*  getModuleNameO  ; 
virtual  RTI::Boolean  localObject ( )  ; 
virtual  RTI : : Boolean  isTerrain ( )  ; 

//  Methods  acting  on  the  RTI 


class  ADMIN_API  Boid  :  public  amObject 

( 

//memeber  variables 
public : 

ACE_Recursive_Thread_Mutex  theMutex; 

//  time  management  data  memeber s 
static  unsigned  int  ms_extentCardinality; 

static  RTI:: Boolean  ms_timeAdvGrant ,- 

static  RTI : : FederationTime  ms_grantTime ; 
static  char*  ms_ModuleName ; 


private: 

RTI : : FederationTime  m_lastTime ; 
nps Geometry*  myGeom; 


virtual  void  sendUpdates (RTI :: FederationTime  newTime) ; 

virtual  void 

sendUpdates (RTI: ; Obj ectID, RTI : : AttributeHandleValuePairSetA, 

RTI: : FederationTime,  RTI: :UserSuppliedTag) ; 

virtual  void  reeeiveUpdates (RTI : :ObjectID  oid, 

const  RTI : :AttributeHandleValuePairSet&  hvps, 

RTI: : FederationTime  ft,  RTI : :UserSuppliedTag  tag); 

void  sendCollisionlnteraction (RTI : : Federat ionTime 

newTime , RTI : : Obj ectID  oid) ; 

virtual  void  sendlnteraction (RTI : : InteractionClassHandle, 

RTI: : ParameterHandleValuePairSetfc.  RTI :: Federat ionTime, 

RTI : : UserSuppliedTag ) ; 

virtual  void  receivelnteraction {  RTI :: InteractionClassHandle 
thelnteraction, 

const  RTI : :ParameterHandleValuePairSetSc  theParameters  ); 


//  Change  flags  for  attibute  values; 

RTI : : Boolean  hasPositionChanged; 

RTI : : Boolean  hasRotationChanged; 


virtual  void  receivelnteraction (RTI :: InteractionClassHandle  ti, 

RTI: :ParameterHandleValuePairSetJ.  phvps.  RTI :: FederationTime  ft, 
RTI : : UserSuppliedTag  tag) ; 


RTI : : Boolean 


localFlag; 


virtual  RTI::Boolean  checkCollision [amObject*  that) ; 


virtual  float  checkTerrainCollision (amObject*  that); 


II  Update  Control  flags 


//  Accessor  Methods 
//  Static  Accessor  Methods 

RTI :: Federat ionTime  GetLastTime ( ) 

(  return  m_lastTime;  ); 

private: 

void  initBoidGeometry  0  ; 

static  void  initBoidFunc (bbObject  'object,  bbData  'data); 
float  distanceFrom (npsVec3  f  thatPos); 
protected: 

RTI: : AttributeHandleValuePairSet*  CreateNVPSet () ; 


. . * . . . . . * . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  Boid.e 
II 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

n 

If  Description:  method  definitions  for  the  Boid  class  — 

//  Boid  class  represents  the  class  that  is  implemented  by  the  amArena 
//  moduLe. 

// 

It  September  1998,  Masters  Thesis 

// . ***** . . . ***** . . 


•include  *RTI.hh* 
•include  ’boid.h" 
•include  'npsGeometry.h” 
•include  "bbKeyboard . h* 
•include  <GL/gl.h> 
•include  'admin. h' 
•include  'amObject.h' 
•include  'amHLAAdmin.h* 


//  Extent  data  memebers 

unsigned  int  Boid: :ms_extentCardinality  =  0; 

char*  Boid: :ms_ModuleName  =  "amBoid"; 

iiuiiiiiiiiimiutinnuiniumiintiiiuniiiiitmnintiiuu 

H  Construction/Destruction 

uiiiuiiiiiitiiiiiiiiumnimuiinnniiiiiniiinniiiinimin 


//  . . . . . . 

//  Function  Name:  Boid(  RTI : :Obj ectID  id) 

II  Task:  constructor  —  instance  intializer 
1 1  Return  Value:  void 
H . * . * . . 

Boid: :Boid(  RTI : : Obj ectID  id) 

: m_lastTime (0.0) ( 

setEntitylD(id) ; 
npsVec3f  XX; 
xx.set(O.Of.O.Of.O.Of) ; 
setPosition (xx) ; 
npsQuaternion  yy; 
setOrientation (yy) ; 

setDamage(lO.O) ; 

localFlag  =  RTI: ;RTI_FALSE; 


initBoidGeometry ( } ; 

Boid: :ms_extentCardinality*+; 


)//end  constructor 


// - 

RTI: : AttributeHandleValuePairSet*  pNvpSet  =  CreateNVPSet ( ) ; 


II  . . . . . * . * . . 

//  Function  Name:  Boid(  ) 

//  Task:  constructor  - -  used  for  object  storage  in  ModuleArray 
//  Return  Value:  void 

//  ** . . . . 

Bold: : Boid ( ) 

:  m_lastTime{0.0) { 

) 


II  * . . . 

//  Function  Name:  ~Boid() 

//  Task:  destructor 

//  Return  Value:  void 

//  . . *’ 

Boid: : -Boid [ } { 

//  remove  the  Object  from  the 

Boid: :ms_extentCardinality — ; 
if (myGeom) 

delete  myGeom; 

>//  end  destructor 


II  ******** . * . * . . 

//  Function  Name:  sendUpdates (RTI : :ObjectID  oid, 

II  RTI :  AttributeHandleValuePairSetSr  ta, 

U  RTI: :FederationTime  ft,  RTI : :UserSuppliedTag  tag) 

//  Task:  not  implemented  in  this  module  --  pure  virtual  function  must 
//  have  definition 

//  Return  Value:  void 


void  Boid: : sendUpdates (RTI: :ObjeetID  oid, 

RTI: AttributeHandleValuePairSetSr  ta, 

RTI : : FederationTime  ft,  RTI : :UserSuppliedTag  tag} 
O 


//  . . . . 

//  Function  Name:  sendUpdates (RTI: : FederationTime  newTime) 

//  Task:  send  handle  value  pair  to  rti  for  update  to  federation 
//  Return  Value:  void 

//  . . . . * . * . . 

void  Boid: : sendUpdates (RTI: : FederationTime  newTime) ( 

// - - 

//  Update  state  of  Boid 


)//  end  for 
)//end  recevieUpdates 


//  . . * . ***** . . 

//  Function  Name:  receivelnteraction (RTI: : Interact ionClassHandle  ieh, 
//  RTI ::  ParameterHandleValuePairSetSr  phvps,  RTI :: FederationTime  ft, 
//  RTI: : UserSuppliedTag  tag) 

//  Task:  not  implemented  in  this  module  --  pure  virtual  function  must 
II  have  definition 

//  Return  Value:  void 

//  . *** . . . . 

void  Boid: : receivelnteraction (RTI: : InteractionClassHandle  ich, 

RTI : : ParameterHandleValuePairSetSr  phvps,  RTI :: FederationTime  ft, 
RTI :  .-UserSuppliedTag  tag) 

O 


// . * . * . . . . 

//  Function  Name:  receivelnteraction ( 

//  RTI :: InteractionClassHandle  thelnteraction, 

//  const  RTI: : ParameterHandleValuePairSetSr  theParameters  ) 

//  Task:  recieves  PHVP  and  decodes  for  use  with  module 
It  Return  Value:  void 

//  . * . . . 

void  Boid: :receiveInteraction (  RTI :: InteractionClassHandle  thelnteraction, 
const  RTI :  ParameterHandleValuePairSetSr  theParameters  H 

if (thelnteraction  ==  Admin : :getCollisionInteractionHandle ()) { 
setDamage (getDamage ( )  -  1.0); 

cout  «  *  "Collision  Detected  —  Object  "  <<  getEntitylD ( ) 

«  *  Damage  =  *  «  getDamage ()  «  endl; 

) 

)//end  receivelnteraction 


II  ***** . . . . . . 

//  Function  Name:  sendCollisionlnteraction ( RTI :: FederationTime  theTime, 
//  RTI: :ObjectID  oid) 

//  Task:  sends  rti  the  PHVP  using  the  send  interaction  fucntion 
II  Return  Value:  void 

//  . *** . . . **** . 

void  Boid: : sendCollisionlnteraction {RTI: : FederationTime  theTime, 

RTI: : Object ID  oid) { 

//build  poramter  handle  value  pair 
RTI : :ParameterHandleValuePairSet*  params  s 
RTI: : Par ameter Set Factory : :create(l) ; 


Admin: : sendEntityUpdate  (  getEntitylD (), “pNvpSet ,  getModuleName {)  ); 


//  set  m_lastTime  to  newTime 
m_lastTime  =  newTime; 

)//  end  sendUpdates 


If  Function  Name:  receiveUpdates (  RTI : :ObjectID  oid, 

//  const  RTI :  : AttributeHandleValuePairSetSr  theAt tributes, 

//  RTI :: FederationTime  theTime,  RTI :: UserSuppliedTag  theTag) 

//  Task:  decodes  HVP  from  RTI  for  this  object 
//  Return  Value:  void 

//  *********** . . . . 

void  Boid: : receiveUpdates (  RTI : : Object ID  oid, 

const  RTI: : AttributeHandleValuePairSetSr  theAttributes , 

RTI :: FederationTime  theTime,  RTI : : UserSuppliedTag  theTag) { 

RTI: :AttributeHandle  attrHandle; 
unsigned  long  valueLength; 

II  We  need  to  iterate  through  the  AttributeHandleValuePairSec 
//  to  extract  each  AttributeHandleValuePair .  Based  on  the  type 
//  specified  (  the  value  returned  by  getHandleO  )  we  need  to 
//  extract  the  data  frlom  the  buffer  that  is  returned  by 
//  getValue{). 

for  {  unsigned  int  i  =  0;  i  <  theAttributes. sire( ) ;  i**  ) 

{ 

attrHandle  =  theAttributes  .getHandle  {  i  ),- 

if  (  attrHandle  ==  Admin : :getPos itionAttrHandle ( )  ) 

{ 

npsVec3f  tmp; 

theAttributes. getValue(  i,  (char*) &tmp,  valueLength  ); 
setPosition(tmp) ; 

) / / end  if 

else  if  (  attrHandle  ==  Admin : :getOrientationAttrHandle ( )  ) 

( 

//  Same  as  above  goes  here... 
npsQuaternion  tmp; 

theAt tributes. getValue(  i,  (char*) ttmp,  valueLength  ); 
setOrientation (tmp) ; 

)//  end  else  if 

else  if  {  attrHandle  s=  Admin : :getVelocityAttrHandle ( )  ) 

{ 

//  Same  as  above  goes  here... 
npsVec3f  tmp; 

theAttributes .getValue (  i,  (char*)&tmp,  valueLength  ); 
setVelocity (tmp) ; 

)//  end  else  if 


par  ams->  add  (Admin:  :getEntity!dHandle  {)  .  (char*)  Stoid. 
sizeof (RTI : :ObjectID) ) ; 

sendlnteraction (Admin: : getCollisionlnteractionHandle ( ) , ‘params, 
theTime. NULL) ; 

}//end  sendCollisionlnteraction 


//  . . . * 

//  Function  Name:  sendlnteraction (RTI :: FederationTime  ft) 

//  Task:  send  the  PHVP  for  the  given  interaction 
//  Return  Value:  void 

//  •«»* . . . . . . . . 

void  Boid: : sendlnteraction (RTI : : InteractionClassHandle  ihc, 

RTI : :ParameterHandleValuePairSetSi  phvps,  RTI : : Federat ionTime  ft, 
RTI: : UserSuppliedTag  tag) { 

try( 

Admin: :ms_rtiAmb->sendInteraction (ihc, phvps, ft, tag) ; 

) 

catch (RTI :: Exceptions  e) { 
cerr  «  *<e  «  endl; 


}//end  sendlnteraction 


//  Function  Name:  CreateNVPSet ( ) 

//  Task:  creates  HVP  set  pertinent  to  this  object 
//  Return  Value:  AttributeHandleValuePairSet* 

,,  . . . . . . . . . . 

RTI; : AttributeHandleValuePairSet*  Boid: :CreateNVPSet () { 

RTI : : AttributeHandleValuePairSet*  pBoidAttributes  s  NULL; 

II  Make  sure  the  RTI  Ambassador  is  set. 
if  {  Admin : :ms_rtiAmb  ) 

( 

// . - . . . . . . 

//  Set  up  the  data  structure  required  to  push  this 
U  objects's  state  to  the  RTI. 

// - - - - - 

RTI: :Obj ectIDcount  numAttributes (3 ) ; 

pBoidAttributes  =  RTI: : AttributeSetFactory : :create (  numAttributes  ); 

pBoidAttributes- >add (  Admin: : getOrientationAttrHandle { ) . 

(char*)  ^orientation, 
sizeof (npsQuaternion)  ) ; 

pBoidAttributes- >add  (  Admin: : getPositionAttrHandle ( ) , 

( char* ) &position, 
sizeof (npsVec3f)  ); 
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pBoidAttributes->add t  Admin: :getVelocityAttrHandle ( ) , 
( char* ) ^velocity , 
sizeof (npsVec3f )  ); 

> 

return  pBoidAttributes ; 

)//  CreateNVPSet ( } 


//  . ***** . . 

//  Function  Name:  display {> 

//  Task:  updates  geometry  position  and  orientation 
//  Return  Value:  void 

//  . * . . 

void  Boid: : display  ()  ( 

myGeom->setPosition(getPosition ( ]  ) ; 
myGeom->setOrientation (getOriencation ( ) ) ; 

)//  end  display 


//  . * . * . . 

//  Function  Name:  createOb ject (RTI : :ObjectID  oid) 

//  Task:  creates  an  object  and  returns  a  pointer  to  it 
//  Return  Value:  amObjeet* 

//  . * . * . . . 

amObjeet*  Boid: : createOb ject (RTI: :ObjectID  oid)  { 

Boid*  tmpBoid  =  new  Boid(oid); 
return  (amObjeet*) tmpBoid; 

}//end  createObject 


//  . ****** 

//  Function  Name:  deleteObject ( ) 
//  Task:  remote  delete  function 
ft  Return  Value:  void 
II  ********* . * . . 

void  Boid: : deleteObject (} { 
delete  this: 


//  . * . . 

//  Function  Name:  getModuleName{ ) 

//  Task:  accessor  method  for  module  name 
//  Return  Value:  char* 

II  * . * . . . . 

char*  Boid: :getHoduleName{ ) { 
return  Boid: :ms_ModuleName; 

)//  getModuleName 


// . * . * . * . 

//  Function  Name:  setLoealObject (RTI :: Boolean  flag) 
//  Task:  set  the  object  as  local  or  not 
//  Return  Value:  void 

//  . ***** 

void  Boid: : setLoealObject (RTI : :Boolean  flag) t 
localFlag  =  flag; 

) 


//  * . * . * . * . 

//  Function  Name:  localObj ect ( ) 

//  Task:  accessor  method  for  local  object  flag 
//  Return  Value:  Boolean 
//  . * . * . 

RTI : : Boolean  Boid : : loca 10b j ect () { 
return  localFlag; 


// . * . . . ***** . . . ******** 

//  Function  Name:  isTerrain() 

//  Task:  informs  amHLAAdmin  whether  the  object  is  a  terrain  object  or  not 
//  Return  Value:  Boolean 

//  . * . ************ . . . * . . 

RTI:: Boolean  Boid: :isTerrain( ) { 
return  RTI: :RTI_FALSE; 

) 


//  . * . ***** . ******** . 

//  Function  Name:  checkCollision (amObj ect*  that) 

//  Task:  retumds  true  if  there  is  a  collision  with  this  object  or  not 
//  Return  Value:  Boolean 

II  . . . 

RTI : : Boolean  Boid: : checkCollision (amObjeet*  that) { 

RTI :  :  Boolean  flag  =  RTI :  : RTI_FALSE ; 
if  (that  ! -  this) ( 

if (distanceFrom (that->getPosition( ) )  <  2) ( 
flag  =  RTI: :RTI_TRUE; 

)//end  if 
)//end  if 
return  flag; 

)//end  checkCollision 


//  . . . . ***** . * . 

//  Function  Name:  hasCollided ( ) 

II  Task:  checks  if  current  object  is  collided  with  any  other  obaject 
//  Return  Value:  Object ID 

//  ******* . * . ***** . . . . . 

RTI: :0bjectID  Boid: :hasCol lided {) ( 


//  ***** . * . . . . . . 

//  Function  Name:  initBoidFunc (bbOb ject  ‘object,  bbData  *data) 
//  Task:  defines  function  for  geometry  callback 
//  Return  Value:  void 

//  . * . . . * . . . . 

void  Boid: : initBoidFunc (bbOb ject  ‘object,  bbData  ‘data) { 

GLfloat  coords [4] [3]  s  (  {  O.Of,  O.Of,  -0.9f).  //  front 

{-0.6f.  O.Of.  0 . 9f } ,  //  back  left 

{  0 . 6 f .  O.Of.  0 .9f } ,  //  back  right 

(  O.Of,  0 . 6f ,  0 . 9f )  //  top 

J; 

glShadeModel (GL_FLAT) ; 
glBegin (GL.TRIANGLES) ; 

{ 

glColor3f (O.Of,  O.Sf.  l.Of);  U  bottom 

glVertex3fv (coords [0] ) ; 
glVertex3 fv (coords (2] ) ; 
glVertex3fv (coords [1]  ) ; 

glColor3f (l.Of,  O.Sf,  O.Of);  II  left 

glVertex3fv(coords(0] ) ; 
glVer tex3£v (coords (1] ) ; 
glVertex3fv (coords [3]  ) ; 

glColor3f (l.Of,  O.Sf,  l.Of);  II  right 

glVer tex3  f v (coords ( 0) ) ; 
glVer tex3fv (coords [ 3  J ) ; 
glVer tex3fv (coords (21 ) ; 

glColor3f (O.Of ,  O.Sf,  O.Of);  //back 

glVertex3fv(coords [1] ) ; 
glVer tex3fv (coords [2) ) ; 
glVertex3fv (coords  13) ) ; 

) 

glEnd ( ) ; 

glShadeModel (GL_SM00TH> ; 

) //end  initBoidFunc 


//  . . . . . ******** . . . 

//  Function  Name:  initBoidGeometry ( ) 

//  Task:  attaches  the  function  for  geometry  callback  to  the  Visual  Module 
//  Return  Value:  void 

//  ***** . * . ***** . ***** . . . 

void  Boid: : initBoidGeometry ( ) { 

myGeom  =  new  npsGeometry(Boid::initBoidFunc); 

myGeom->set8oundingSphere (npsVec4f (O.Of,  O.Of,  O.Of,  l.Of)); 

)//  end  initBoidGeometry 


//  loop  amObjeet  array 
//  compute  distance 
RTI: : Obj ectID  oid  =  0; 

amObjeet*  tmp  =  Admin:  .-checkEntityCollision (this)  ; 
if  (tmp  fcfc  (tmp  !=  this)  )( 

if  (( (tmp->getVelocity() )  .lengthO  <  (this->getVelocity() )  .lengthO  ) )  ( 
oid  *  tmp->getEntityID( ) ; 

}//end  if 
) //end  if 

return  oid; 

>//end  hasCollided 


//  . . * . 

//  Function  Name:  distanceFrom (npsVec3f  thatPos) 
//  Task:  finds  distance  between  two  objects 
//  Return  Value:  float 
//  . . 

float  Boid: :distanceFrom (npsVecl f  thatPos) { 

npsVec3f  thisPos  =  this->getPosition ( ) ; 

npsVec3f  tmpPos; 

tmpPos. sub (thatPos, thisPos) ; 

return  tmpPos . length ( ) ; 

}//end  distanceFrom 


//  . ******* . . . . . *..**.*.*< 

//  Function  Name:  eheckTerrainCollision (amObjeet*  that) 

//  Task:  returns  y  value  for  terrain  to  provide  rudimentary  terrain 
//  collision  detection  —  0.0  because  not  a  terrain  module 
//  Return  Value:  void 

//  . . ***** . . . . 

float  Boid: : eheckTerrainCollision (amObjeet*  that) { 
return  0.0; 

}//end  eheckTerrainCollision 


63 


This  is  the  module.txt  file  for  amAr< 


module 


amArena  Files 


Bamboo 1 . Ob 
3 

bbKeyboa  r dModu 1 e 
npsVisualModule 
amHLAAdmin 


//  . . . . . * . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  module. h 
// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
II 

//  Description:  This  file  defines  the  global  functions  required  by  every 
//  dynamically-linked  library.  How  these  functions  are 

//  implemented  is  arbitrary,  but  it  is  useful  have  RCS 

//  automate  some  of  the  work. 

It 

//  September  1998.  Masters  Thesis 

// . . . . . * . . . * 


#ifndef  module 
•define  _ module 


//  . . . 

//  INCLUDES  AND  EXTERNS 

//  . . 


// . *" 

//  DEFINES 
II  * . . 


//  . . ********** . 

II  FUNCTION  PROTOTYPE  SPECIFICATIONS 


•ifdef  _ eplusplus 

extern  "C"  { 

•endif 

ADMIN^API  const  char  "getModuleName ( ) ; 
ADMIN_API  float  getModuleVersion ( ) ; 
ADMIN_API  const  char  "getModuleDate () ; 
ADMIN_API  const  char  *getModul eText ( ) ; 
ADKIN_API  bool  initModule ( ) ; 

ADMIN_API  bool  exitModule { ) ; 

•ifdef  _ eplusplus 

) ; 

•endif 

•endif  II  _ module 


//  . . ********* . . . .  .  . 

//  EXECUTIVE  SUMMARY 
1/ 

II  File  Name:  module. c 
// 

II  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

II  Description:  This  file  defines  the  global  functions  required  by  every 
//  dynamically-linked  library.  How  these  functions  are 

II  implemented  is  arbitrary,  but  it  is  useful  have  RCS 

//  automate  some  of  the  work. 

U 

II  September  1998,  Masters  Thesis 

II  ****** . ***** . * . * . . . 


// . *** . . 

II  INCLUDES  AND  EXTERNS 

//  . . 

•include  <stdio.h> 

•include  <stdlib.h>  //  atof 

•include  "module. h* 

•include  ’amArena.h" 


//  ****** . * . . 

//  DEFINES  &  FILE  SCOPE  VARIABLES 

//  . . . 


n  . 

/ /  CODE 
U . * 


const  char  *getModuleName ( ) 

{ 

return  " amArena  *  ; 

} 


float  getModuleVersion ( ) 
{ 

return  l.Of; 


const  char  *getModuleDate () 

{ 

return  "1998/08/01  06:00:48"; 

) 


const  char  "getModuleText { ) 
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return  'amArena  Terrain  module  --  T  to  load"; 


bool  initModuleO 


initamArena ( ) ; 
return  l ; 

} 


//  EXECUTIVE  SUMMARY 

// 

//  File  Name:  amArena.h 

// 

//  Author:  CPT  Stewart  Liles,  Naval  postgraduate  School 
// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
It 

//  September  1998.  Masters  Thesis 


bool  exitModulel) 

{ 

exitamArena ( J ; 


#i£ndef  _amArena 
#define  _amArena 


ft  INCLUDES  AND  EXTERNS 


//  FUNCTION  PROTOTYPE  SPECIFICATIONS 


void  initamArena ( ) ; 


•oid  exitamArena {) ; 


//  INLINED  MEMBER  FUNCTIONS 


It  EXECUTIVE  SUMMARY 


II  File  Name:  amArena.c 


II  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
It 

II  September  1998,  Masters  Thesis 


INCLUDES  AND  EXTERNS 

"Rti.hh" 

"npsVisual .h" 
"npsWindow.h" 
"npsViewport .h" 
"bbMouse ,h" 
"bbKeyboard.h" 
"bbEventResponse . h* 
"bbCallback.h" 
"npsGeometry .h" 
‘Arena, h’ 

"anHLAAdmin . h* 

"admin. h" 
t  "amObject.h* 


# include  <math.h> 
•include  <GL/gl.h> 

•ifdef  SGI 

•include  "bbSGI.h* 
•endif 


II  prototypes 

void  initKeyboardModuleO  ; 
void  initVisualModule ( ) ; 

II  instance  a  Arena  Object  and  pass  it  to  the  module  array 
myArena  =  new  Arena ( ) r 

Admin: :addModuleFunctionPointer (myArena) ; 

//this  is  a  Terrain  module  so  if  one  already  exists  we  must  delete  it 
if  (Admin: :ms_Terrain) { 

Admin : : unloadModule (Admin: :ms_Terrain->getModuleName () )  ; 

} //end  if 

initKeyboardModule ( ) ; 

//  null  my  Arena  for  future  use 
myArena  =  NULL; 

//  add  object  to  the  federation 
if ( 'myArena) { 

RTI : :ObjectID  oid  =  Admin : :registerObject () ; 
amObject*  tmp  =  Admin :: findModule ( "amArena" ) ; 

npsGeometry*  arenaPtr  -  npsGeometry ::  f  indOb  j  ect  ( "amArena_Geom" )  ,- 
if  (! arenaPtr )( 

initVisualModule ( ) ; 

) 

myArena  =  (Arena* ) cmp->createOb ject (oid) ; 
myArena->setLocalObject (RTI: :RTI_TRUE) ; 

Admin : :ms_Terrain  =  myArena; 

}//end  if 

//  this  allows  Arena  to  update  to  rest  of  federation 
if (myArena) ( 

myArena->setUpdateFlag(RTI : :RTI_TRUE) ; 


>//  end  initamArena 


Arena  ‘myArena ; 
int  mouselnWindow [ ) ; 


//  Function  Name:  initamArena ( ) 

//  Task:  initialize  Module  —  this  is  ruj 
//  Return  Value:  void 


void  initamArena!)  ( 


II  Function  Name:  exitamArena () 

I!  Task:  does  housekeeping  required  to  exit  the  Module 
//  this  is  run  only  once 
//  Return  Value:  void 


oid  exitamArena ( ) ( 

bbCa 1 lba  ckHandler  *ea 1 lba  ckHandl er ; 
bbCallback  'callback; 

bbKeyboard*  keyboard; 

bbEventResponse*  eventResponse; 

keyboard  =  bbKeyboard: :getlnstance ( ) ; 

//  remove  keyboard  callbacks 
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//  LoadArena  callback 

eventResponse  =  bbEventResponse : : findObject ( *amArenaER_Terrain“ } ; 
callback  =  bbCallback::findObject("amArena_Terrain*); 
eventResponse->removeCallbaek( callback) ; 
delate  callback; 

//  remove  remote  amObjects 
if (Admin : :ms_Terrain) { 

Admin: :removeAmObject (Admin: :ms_Terrain->getEntityID [) ) ; 

) 

//remove  local  object 
if ( ! myArena ) { 

npsGeometry*  tmp  =  npsGeometry: : findObject ( *amArena_Geom“ ) ; 
i f ( tmp ) 

delete  tmp; 

) / / end  else 

//  remove  the  module  from  module  list 
Admin: : removeModule { 'amArena* )  ; 

Admin: :ms_Terra in  =  NULL; 

cout  «  'exitamArena*  «  endl; 

)  //end  exitamArena 


//  . . . . * . . 

//  Function  Name:  initKeyboardModule { ) 
//  Task:  add  keyboard  callbacks 
//  Return  Value:  void 


void  initKeyboardModule ( ) 

{ 

void  escFunc (bbObject  "object,  bbData  "data); 
void  resetFunc (bbObject  "object,  bbData  "data); 
void  loadArena (bbObject  "object,  bbData  "data); 


bbKeyboard 
bbEven  t  Re  s  pons  e 
bbCallback 


•keyboard; 

* event Res pons e; 
"callback; 


//  get  the  keyboard  device 
keyboard  =  bbKeyboard: :getlnstance ()  ; 


//  set  up  load  boid  key 

eventResponse  =  new  bbEventResponse (bbKeyboard: :KEY_T  | 
bbKeyboard: :DOWN_TRANS) ; 

eventResponse->setName ("amArenaER_Terrain* ) ; 
callback  -  new  bbCallback ()  ; 
callback->setName ( *amArena_Terrain* ) ; 
callback->setFune (loadArena) ; 
eventResponse->addCallbackLast (callback) ; 


keyboard->addEventResponse (eventResponse) ; 


//  Function  Name:  initVisualModule ( ) 

//  Task:  set  the  geometry  for  the  Arena 
//  Return  Value:  void 
//  * . . 


void  initVisualModule  ( )  ( 

void  initArenaFunc (bbOb j ect  "object,  bbData  "data); 
npsGeometry  "arena; 

//  init  geometry 

arena  =  new  npsGeometry ( initArenaFunc) ; 
arena->setName { “amArena_Geom" ) ; 

}  //  end  initVisualModule 


//  Function  Name:  loadArena (bbObject  "object,  bbData  "data) 

//  Task:  function  defined  for  the  loadArena  keyboard  callback 
//  Return  Value:  void 


void  loadArena (bbObject  "object,  bbData  "data) { 
void  initVisualModule () ; 

if  (mouselnWindow () ) { 

cout  «  'loadArena*  «  endl; 

if  ( imyArena) £ 

//add  Arena  to  federation  if  does  not  exist 
RTI: : Object ID  oid  =  Admin: :registerObj ect () ; 
amobject*  tmp  =  Admin :: findModule ( 'amArena* ) ; 

npsGeometry*  arenaPtr  =  npsGeometry :: findObject ('amArena_Geom* ) ; 
if  (! arenaPtr )( 

initVisualModule {) ; 

3 

myArena  =  (Arena* ) tmp->createObject (oid) ; 
my Arena ->setLoca 10b j ect (RTI: :RTI_TRUE) ; 

Admin: :ms_Terrain  =  myArena; 

)//end  if 

//set  flag  so  Arena  is  updated  and  the  rest  of  the  federation 
//  will  discover  the  object 
if (myArena) ( 

myArena->setUpdateFlag (RTI : :RTI_TRUE) ; 

) 

}//end  if 


//  Function  Name:  initArenaFunc (bbObject  "object,  bbData  "data) 
//  Task:  function  defining  the  Arena  geometry 
//  Return  Value:  void 

//  . . . . . 

void  initArenaFunc (bbObject  "object,  bbData  "data) { 
npsGeometry  "geometry; 

uint  displayListNum; 

const  float  CELL_LENGTH  =5.0; 

#ifdef  VISUALCPP 


const  uint 
const  uint 
#elif  SGI 

const  uint 
const  uint 

#endif 
const  uint 
const  uint 
const  uint 
const  uint 
uint 
bool 

GLfloat 
GLfloat 
GLfloat 


N1TM_CELLS_L0NG  =  10; 

NTJM_C  ELL  S_W  IDE  =  10; 

NUM_CELLS_LONG  =  50; 

NUM_C  ELLS_W IDE  =  50; 

TOTAL_NUM_C ELLS  =  NUM_CELLS_LONG  '  NUM_CELLS_WIDE; 
NUM_VERTS_LONG  =  NUM_C EL LS_L0NG  *  1; 

NUM_VERTS_WIDE  =  NUM_CELLS_WIDE  +  1; 
TOTAL_NUM_VERTS  =  NUM_VERTS_LONG  •  NUM_VERTS_WIDE ; 
i,  j,  currVert,  cur r Index,  currCell; 
colorToggle; 

coords ( TOTAL_NUM_VERTS ) £3) ; 
normals [TOTAL_NUM_VERTS] £3)  ; 
textures [TOTAL_NUM_VERTS ]  [2]  ; 


//  init  Vais 
colorToggle  =  0; 

for  (i  =  0 ;  i<NUM_VERTS_LONG ;  i**){ 
for  (j=0;  j <NUM_VERTS_WIDE ;  j  *♦ ) £ 
currVert  =  i"NUM_VERTS_WIDE  +  j; 

coords (currVert ) £0]  =  (CELL_LENGTH  *  i)  - 
(NUM_CELLS_LONG"CELL_LENGTK"0. 5f)  ; 

coords (currVert] £1]  =  O.Of; 
coords  £ currVert )£2]  =  ( -CELL_LENGTH  "jl* 
(NUM_CELLS_WIDE"CELL_LENGTH"0 . 5f )  ; 

normals (currVert] [0]  =  O.Of; 
normals (currVert] [1]  =  l.Of; 
normals (currVert] (23  =  O.Of; 

textures [currVert] [0]  =  ( ( float) i) / (NUM_VERTS_LONG-l) ; 
textures [currVert ] [1]  =  ({ float) j )/ <NUM_V£RTS_WIDE-1) ; 
) / / end  for  j 
)//end  for  i 

glShadeModel (GL_FLAT) ; 


colorToggle  =  0; 

for  (i=0 ;  i<NUM_CELLS_LONC;  i+*>  { 


66 


glBegin (CL_TRIANGLE_STRIP) ; 

(  //start  gl 

for  (5=0;  j<NUM_VERTS_WIDE;  j**)  { 
if  (colorToggle) { 
colorToggle  =  0; 
glColor3f (O.Of.  O.Of,  l.Of); 

) 

else{ 

colorToggle  =  1; 
glColor3f (l.Of.  l.Of.  l.Of); 

) 

currVert  =  i*NUM_VERTS_WIDE  -  j; 
glVertex3fv( coords (currVert) ) ; 

currVert  =  (i*l) *NUM_VERTS_WIDE  *  j; 
glVertex3fv (coords [currVert] ) ; 

)//end  for 

if  (  NUM__CELLS_WIDE  S.  0x1  )[ 
if  (colorToggle) 
colorToggle  =  0; 
else 

colorToggle  =  1; 

} 

)//end  gl 
glEndO  ; 

) / /end  for 

//  walls  and  ceiling 
//North  wall 
glBegin (GL.POLYGON) ; 

glColor3£ { 0 . 5f , 0 . Sf . 0 . 5f ) ; 
glVertex3f (-25. Of. O.Of, -25 .Of) ; 
glVertex3f (25. Of, O.Of, -25. Of)  ; 
glVertex3f (25. Of, 50. Of, -25. Of) ; 
glVertex3f (-25. Of. 50. Of, -25. Of); 
glEnd ( ) ; 

//South  wall 
glBegin (GL_POLYGON)  ; 

glColor3f (0.6f.0.6f,0.6f); 
glVertex3f (-2 5. Of, O.Of, 25. Of) ; 
glVertex3f (25 .Of ,0.0f, 2S.0f); 
glVertex3f (25. Of, 50. Of, 25. Of)  ; 
glVertex3f ( -25 .Of . 50 . Of , 25 .Of) ; 
glEnd ( )  ; 

//West  wall 
glBegin (CL_POLYGON) ; 

glColor3f (0 . 6f , 0 . 5f , 0 .4f ) ; 
glVertex3f (-25, Of, O.Of ,25. Of); 
glVertex3f (-25 .Of, 0  .Of . -25. Of) ; 
glVertex3  f (-25 . Of , 50 .Of , -25 . Of ) ; 
glVertex3f (-25. Of, SO. Of, 25. Of) ; 
glEnd ( ) ; 

//East  wall 
glBegin (GL_POLYGON) ; 

glColor3f (0 .4f , O.Sf ,0.9f) ; 
glVer tex3f (25. Of, O.Of, -25. Of) ; 


g!Vertex3f {25 .Of . 0  .Of , 
glVertex3f (25. Of. SO. Of 
glVertex3  f (25 . Of , 50. Of 
glEnd ( ) ; 

//ceiling  wall 
gl Begin (GL_POLYGON) ; 

glColor3f (0.8f,0.8f,0. 
glVertex3£ (-25 .Of,  50.0 
glVercex3f (25 . Of , SO . Of 
glVertex3f (25 . Of . 50. Of 
g!Vertex3f (-25 . Of ,  50 . 0 
glEndO; 

glShadeModel (GL_SMOOTH) ; 

} / /initArenaFune 


//  Function  Name:  mouselnWindowf ) 

//  Task ;  tells  if  mouse  is  in  the  correct  window  to  receive  keyboard 


int  mouseInWindow( )  ( 

int  flag  =  0; 

npsWindow  “window; 

npsViewport  “viewport; 

window  =  npsWindow: : findObject [ * AdminWindow* ) ; 

viewport  =  npsViewport :: findObject ( “AdminViewport"  )  ; 

float  x, y; 

X  =  bbMouse: :getX() ; 
y  =  bbMouse : : getY ( ) ; 
bbScreen:  :normalizeVal  (fcx,  &  y)  ; 

if  (viewport- >getWindow ( ) ->isValInside (x,y) ) { 
flag  =  1; 


//  EXECUTIVE  SUMMARY 


File  Name:  Arena. h 


H  Author:  CPT  Stewart  Liles.  Naval  Postgraduate  School 
// 

//  Description:  method  definitions  for  the  Arena  class  -- 

//  Arena  class  represents  the  class  that  is  implemented  by  the  amArena 


//  September  1998,  Masters  Thesis 


♦include  “Rti.hh" 

♦include  “npsVec3f.h“ 
♦include  "npsGeometry .h* 
♦include  *bbKeyboard.h“ 
♦include  * amObject. h* 
♦include  “admin. h* 

♦ifndef  ADMIN_API 
♦ifdef  VISUALCPP 

♦define  ADMIN_API  _< 
♦else 

♦define  ADMIN_API 
♦endif 
lendif 


_ declspec (dllimport) 


class  ADMIN_API  Arena  :  public  amObject 


//memeber  variables 
public: 

//  Extent  data  memebers 
static  char*  ms_ModuleName 


//  Change  flags  for  attibute  values 


virtual  void  display (); 

virtual  amObject*  createObject (RTI : :0b jeetID  oid) ; 
virtual  char*  getModuleName () ; 
virtual  RTI : : Boolean  localObj ect 1 ) ; 
virtual  RTI::Boolean  isTerrainO; 

//  Methods  acting  on  the  RTI 

virtual  void  sendUpdates (RTI : : FederationTime  newTime) ; 

virtual  void 

sendUpdates (RTI ::ObjectID, RTI: : AttributeHandleValuePairSetfc, 

RTI : : FederationTime,  RTI : :UserSuppliedTag) ; 

virtual  void  reeeiveUpdates (RTI :: Object ID  oid, 

const  RTI : : AttributeHandleValuePairSetfc  hvps, 

RTI :: FederationTime  ft,  RTI : : UserSuppliedTag  tag); 

virtual  void  sendlnteraction (RTI: : InteractionClassHandle, 

RTI: :ParameterHandleValuePairSeti,  RTI: : FederationTime. 

RTI : : UserSuppliedTag) ; 

virtual  void  sendlnteraction (RTI :: FederationTime)  ; 

virtual  void  receivelnteraction (  RTI: : InteractionClassHandle 
thelnteraction, 

const  RTI: :ParameterHandleValuePairSet£.  theParameters  ); 

virtual  void  receivelnteraction (RTI: : InteractionClassHandle, 

RTI : : ParameterHandleValuePairSetfc.  RTI : : FederationTime. 

RTI : : UserSuppliedTag) ; 

virtual  RTI::Boolean  checked lis ion (amObject*  that); 
virtual  float  checkTerrainCollision (amObject*  that); 
virtual  void  deleteObject () ; 


RTI : : Boole; 
RTI : : Boole* 


1 oca 1 Flag ; 
updateFlag; 


tnly  single  update 


//  member  functions 
public: 

Arena ( ) ; 

Arena {  RTI : :ObjeetID  id) ; 

void  setLocalObject (RTI: : Boolean) ; 

void  setUpdateFlag (RTI : : Boolean) ; 

virtual  -Arena ( ) ; 


EXECUTIVE  SUMMARY 


Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 

Description:  method  definitions  for  the  Arena  class  -- 

Arena  class  represents  the  class  that  is  implemented  by  the  amArena 
module. 

September  1998.  Masters  Thesis 


♦include  “RTI.hh* 

♦ include  “Arena. h* 
♦include  “npsGeometry .h* 
♦include  *bbKeyboard.h“ 
♦include  <CL/gl.h> 
♦include  “admin. h* 
♦include  “amObject.h" 
♦include  “amHLAAdmin.h* 


//  Extent  data  memebers 
char*  Arena : :ms_ModuleName  =  “amArena* ; 


//////////////////////////////////////////////////// mmuunntu 

II  Construction/Destruction 

umuiuiiuiiiiinmiiuuinniimniiiiiinuitnuiaiiiuini 


//  Function  Name:  Arena (  RTI ; :0b jectID  id) 
//  Task;  constructor  —  instance  intializer 
//  Return  Value:  void 


Arena :: Arena (  RTI : : ObjectID  id)  { 
cout  «  “Arena (oid) *  «  id  «  ei 


setEntity ID ( id)  ; 
npsVec3f  xx ; 
xx.set(O.Of.O.Of.O.Of) ; 
setPosition (xx) ; 
npsQuatemion  yy; 
setOrientation (yy) ; 

localFlag  =  RTI : : RTI_FALSE; 
updateFlag  =  RTI : : RTI_TRUE; 

Admin: :ms_Terrain  =  this; 
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) / /end  constructor 


//  . . . . . . . . 

//  Function  Name:  Arena (  ) 

//  Task:  constructor  --  used  for  object  storage  in  ModuleArray 
//  Return  Value:  void 

//  . . . . . ***- 

Arena : :Arena () { 

)//end  default  constructor 


II  . . * . . . . 

II  Function  Name:  -Arena () 

II  Task:  destructor 
//  Return  Value:  void 

//  . . * . . 

Arena : : -Arena ( ) 

{ 

cout  «  "The  arena  geometry  was  just  deleted\n* 

«  "If  you  deleted  the  terrain  ignore  message \n* 

«  "else  a  federate  just  quit  the  federation \n* 

<<  "PUSH  T  to  display  terrain* 

«  endl; 

npsGeometry*  trip  =  npsGeometry : : f indObject ( “amArena_Geom") ; 

delete  tmp; 


)//end  destructor 


//  . * . * . . . . 

//  Function  Name:  sendUpdates (RTI: :ObjectlD  oid, 

RTI: : AttributeHandleValuePairSet^  ta, 

II  RTI : :FederationTime  ft,  RTI : :UserSuppliedTag  tag) 

II  Task:  not  implemented  in  this  module  —  pure  virtual  function  must 
//  have  definition 

//  Return  Value:  void 

//  . * . . . . . . 

void  Arena: : sendUpdates (RTI: : Ob jectID  oid,  RTI : :AttributeHandleValuePairSet& 
ta, 

RTI : : FederationTime  ft,  RTI : :UserSuppliedTag  tag) 

{) 


// . . . . . . . . 

U  Function  Name:  sendUpdates (RTI :: FederationTime  newTime) 

II  Task:  send  handle  value  pair  to  rti  for  update  to  federation 
II  Return  Value:  void 

//  . * . . 

void  Arena : : sendUpdates (RTI : : FederationTime  newTime) ( 


void  Arena: : receivelnteraction (RTI: : Interact ionClassHandle  ich, 

RTI :: Parameter HandleValuePairSetfc  phvps,  RTI :: FederationTime  ft. 
RTI : :UserSuppliedTag  tag) 

O 


// . . . * . . 

II  Function  Name:  receivelnteraction (  RTI: : Interact ionClassHandle 
the In  t  era  ct i on , 

//  const  RTI: :ParameterHandleValuePairSett  theParameters  ) 

II  Task:  not  implemented  in  this  module  --  pure  virtual  function  must 
//  have  definition 
II  Return  Value:  void 

//  . * . . . * . . . . . . 


void  Arena: : receivelnteraction  (  RTI : : InteractionClassHandle  thelnteraction. 

const  RTI : : ParameterHandleValuePairSetfic  theParameters  ) 

{)//end  receivelnteraction 


// . * . ** . . . . . 

//  Function  Name:  sendlnteract ion {RTI :: FederationTime  ft) 

//  Task:  not  implemented  in  this  module  --  pure  virtual  function  must 
//  have  definition 
//  Return  Value:  void 

//  . . . . . . 

void  Arena : : sendlnteraction (RTI : : FederationTime  ft ) 

U 


//  . . . . 

//  Function  Name:  sendlnteraction (RTI :: InteractionClassHandle  ihc, 

//  RTI : : ParameterHondleValuePairSeti  phvps,  RTI :: FederationTime  ft, 
//  RTI : :UserSuppliedTag  tag) 

//  Task:  not  implemented  in  this  module  —  pure  virtual  function  must 
//  have  definition 

//  Return  Value:  void 

// . . . . . . 

void  Arena: : sendlnteraction (RTI :: InteractionClassHandle  ihc, 

RTI : : ParameterHandleValuePairSeti  phvps,  RTI :: FederationTime  ft, 
RTI : : UserSuppl iedTag  tag ) 

n 


//  . * . * . . . . 

//  Function  Name:  CreateNVPSet { ) 

//  Task:  creates  HVP  set  pertinent  to  this  object 
//  Return  Value:  AttributeHandleValuePairSet* 

II  . . . . . . 

RTI : : AttributeHandleValuePairSet"  Arena: :CreateNVPSet {) ( 

RTI : :AttributeHandleValuePairSet *  pArenaAttributes  =  NULL; 


if (updateFlag)  ( 

RTI: : AttributeHandleValuePairSet*  pNvpSet  =  CreateNVPSet () ; 

Admin : : sendEntityUpdate (  getEntityIDO  , ‘pNvpSet,  getModuleName ( )  ); 

updateFlag  =  RTI : : RTI_FALSE ; 

)//end  if 

}//  end  sendUpdates 


//  . . . . . . . . . 

If  Function  Name:  receiveUpdates (  RTI : :Ob jectID  oid, const 
RTI : :AttributeHandleValuePairSet&  theAttributes, 

//  RTI :: FederationTime  theTime,  RTI :: UserSuppl iedTag  theTag) 

II  Task:  decodes  HVP  from  RTI  for  this  object 
II  Return  Value:  void 

//  . . . . . . 

void  Arena :: receiveUpdates (  RTI : :ObjectID  oid, const 
RTI: :AttributeHandleValuePairSet4  theAttributes, 

RTI: : FederationTime  theTime,  RTI :: UserSuppl iedTag  theTag) { 
RTI: : AttributeHandle  attrHandle; 
unsigned  long  valueLength; 

//  We  need  to  iterate  through  the  AttributeHandleValuePairSet 
//  to  extract  each  Attr ibuteHandleValuePair .  Based  on  the  type 
//  specified  (  the  value  returned  by  gecHandleO  )  we  need  to 
//  extract  the  data  frlom  the  buffer  that  is  returned  by 
//  getValuef). 

for  (  unsigned  inc  i  =  0;  i  <  theAttributes .size () ;  i++  } 

{ 

attrHandle  =  theAttributes . getHandle (  i  ); 

if  (  attrHandle  ==  Admin: :getPositionAttrHandle( )  ) 

< 

npsVec3f  tmp; 

theAttributes .getValue [  i,  (char*) &tmp,  valueLength  ); 
setPosition(tmp) ; 

> //end  if 

>//  end  for 

}//end  recevieUpdates 


//  . . . . 

//  Function  Name:  receivelnteraction (RTI: : InteractionClassHandle  ich. 
//  RTI : : ParameterHandleValuePairSeti  phvps,  RTI :: FederationTime  ft, 

//  RTI :: UserSuppl iedTag  tag) 

//  Task:  not  implemented  in  this  module  —  pure  virtual  function  must 
//  have  definition 

//  Return  Value:  void 

//  . . . * . . . * . . 


//  Make  sure  the  RTI  Ambassador  is  set. 
if  (  Admin: sms^rtiAmb  ) 

{ 

// . 

//  Set  up  the  data  structure  required  to  push  this 
//  objects's  state  to  the  RTI. 

// . - - - - - - - - - 

RTI: : Ob j ectIDcount  numAttributes (1) ; 

pArenaAttributes  =  RTI : :AttributeSetFactory :: create (  numAttributes  >; 

pArenaAttributes->add(  Admin: :getPositionAttrHandle { ) , 

(char * ) ^position, 
siseof (npsVec3f )  ); 

} 

return  pArenaAttributes; 

) / / end  CreateNVPSet ( > 


//  . . . . . . . . . . 

//  Function  Name:  display () 

//  Task:  not  implemented  in  this  module  —  pure  virtual  function  must 
//  have  definition 
//  Return  Value:  void 

//  ******* . * . . . 

void  Arena: :display() { 

)//  end  display 


//  . . . . ...., 

//  Function  Name:  createObject (RTI : :Ob jectID  oid) 

//  Task:  creates  an  object  and  returns  a  pointer  to  it 
//  Return  Value:  amObject* 

//  . . . . . . 

amObject*  Arena: : createObject (RTI :: Ob j ect ID  oid) { 

Arena*  tmpArena  =  new  Arena (oid); 
return  (amObject*) tmpArena; 

)//end  createObject 


//  *********** . . . . 

//  Function  Name:  getModuleName ( ) 

//  Task:  accessor  method  for  module  name 
//  Return  Value:  char* 

//  . . . . . . 

char*  Arena : : getModuleName { ) { 
return  Arena : :ms_ModuleName; 

)//  getModuleName 
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//  Function  Name:  setLocalObject (RTI : : Boolean  flag) 
//  Task:  set  the  object  as  local  or  not 
//  Return  Value:  void 

//  * . ******* . * . 

void  Arena: : setLocalObject (RTI : : Boolean  flag) { 
localriag  =  flag; 

}//end  setLocalObject 


//  Function  Name:  localObj ect ( } 

//  Task:  accessor  method  for  local  object  flag 
//  Return  Value:  Boolean 


RTI : : Boo lean  Arena: : localObject ( ) { 
return  localFlag; 

}//end  localObject 


//  Function  Name:  isTerrain () 

//  Task:  informs  amHLAAdroin  whether  the  object  is  a  terrain  object  or  not 
//  Return  Value:  Boolean 


RTI : : Boolean  Arena : : isTerrain ( ) { 
return  RTI: :RTI_TRUE; 

) //end  isTerrain 


//  Function  Name:  setUpdateFlag (RTI :: Boolean  flag) 

//  Task:  sets  update  flag  --  used  in  send  updates  to  decide  whether  to 
//  transmit  a  HVP  or  not 
//  Return  Value:  void 


void  Arena :: setUpdateFlag (RTI : :Boolean  flag)( 
updateFlag  =  flag; 

}//end  setUpdateFlag 


//  Function  Name:  checkCollision (amObject*  that) 

//  Task:  returnds  true  if  there  is  a  collision  with  this  object  or  i 
//  Return  Value:  Boolean 


RTI : : Boolean  Arena :: checkCollision (anObj ect •  that)< 


RTI : : Boolean  flag  =  RTI : :RTI_FALSE; 


//  floor  ckeck 

if  {  (that- >getPosit  ion  { )  )  .get  (1)  <  O.SfH 


amPageModule  Files 


flag  =  RTI: :RTI_TRUE; 

} 

//  ceiling  check 

else  if ( (that->getPosition I ) ) .get (1)  >  49.0f)( 
flag  =  RTI: :RTI_TRUE; 

> 

//  North  wall  check 

else  if ( (that->getPosition() ) -get (2)  <  -24.0f){ 
flag  =  RTI: :RTI_TRUE; 

} 

//  south  Wall  check 

else  if { (that->getPosition() ) .get (2)  >  24. Of) [ 
flag  =  RTI: :RTI_TRUE; 

> 

//  West  wall  check 

else  if ( (that->getPosition() ) -get (0)  <  -24.0f){ 
flag  =  RTI: :RTI_TRUE; 

) 

//  East  wall  check 

else  if ( (that->getPosition() ) .get(O)  >  24.0f)C 
flag  =  RTI : :RTI_TRUE; 


return  flag; 

)//end  checkCollision 


//  Function  Name:  checkTerrainCollisionlamObjecc*  that) 

//  Task:  returns  y  value  for  terrain  to  provide  rudimentary  terrain 
//  collision  detection 
//  Return  Value:  void 

//  . . . . ****** . ******* . * . . . 

float  Arena:  .-eheckTerrainCollision (amObject*  that)  ( 
float  yPosition  =  0.0; 

if ( (that->getPosition ( } 1 .get (1)  <  0.5)  { 
yPosition  =  0.5; 

> 

return  yPosition; 

) / / end  eheckTerrainCollision 


//  Function  Name:  deleteObject () 
//  Task:  remote  delete  function 
//  Return  Value:  void 


void  Arena :: deleteObject () { 


This  is  the  module.txt  file  for  amPageModule  module. 


bbKeyboa rdModu le 

bbMouseModule 

npsVisualModule 
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//  . * . * . * . . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  module. h 
// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
// 

//  September  1998,  Masters  Thesis 

//  . * . * . * . 

#ifndef  _ module 

•define  _ module 

//  . . . . . . 

//  FUNCTION  PROTOTYPE  SPECIFICATIONS 

// . * . * . . . * . 

•ifdef  _ cplusplus 

extern  "C"  { 

•endif 

ADMIN_API  const  char  "getModuleName () ; 

ADMIN_API  float  getModuleVersion f ) ; 

ADKIN_API  const  char  "getModuleDate ( ) ; 

ADMIN_API  const  char  "getModuleText ( ) ; 

ADMIN_API  bool  initModule ( ) ; 

ADMIN_API  bool  exitModule  ( 1 ; 

•ifdef  _ cplusplus 

>; 

#endif 

#endif  //  _ module 


//  . . . . . 

//  EXECUTIVE  SUMMARY 
II 

//  File  Name:  module, c 
1/ 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
II 

/ /  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
II 

//  September  1996,  Masters  Thesis 

II  . . . . . . . . . . . 


//  ************ . . . . . . 

//  INCLUDES  AND  EXTERNS 

//  . . . * . . . . . 

# include  "module. h" 

# include  "amPageModule ,h* 

//  . . . . * . 

/  /  CODE 

//  . * . * . * . . . . . 

const  char  "getModuleName ( ) 

{ 

return  "amPageModule"; 

> 

float  getModuleVersion { ) 

{ 

return  1.0; 

) 

const  char  "getModuleDate ( ) 

{ 

return  “1998/09/01  06:05:48"; 

) 

const  char  "getModuleText ( ) 

{ 

return  "This  module  enables  the  user  to  dynamically  page  modules  in\n 

and  out  of  the  system  via  pressing  the  L  and  U  keys  respectively' 

) 


bool  initModule () 

{ 

initamPageModule ( ) ; 
return  1; 

> 


//  . . * . * . * . . . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  amPageModule . h 

// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
// 

//  September  1998,  Masters  Thesis 

//  . . . . . . 

•ifndef  _amPageModule 
•define  _amPageModule 


bool  exitModule [) 
{ 

return  1; 

) 


//  . . . . . 

//  EXECUTIVE  SUMMARY 
// 

//  File  Name:  amPageModule . c 
// 

//  Author:  CPT  Stewart  Liles,  Naval  Postgraduate  School 
// 

//  Description:  defines  methods  pertinent  to  module  loading  and  unloading 
// 

//  September  1998,  Masters  Thesis 

//  * . . . ***** . 

//  . . * . * . . . * . . . . 

//  INCLUDES  AND  EXTERNS 

//  . . . . . . . . . 


//  . . . 

//  FUNCTION  PROTOTYPE  SPECIFICATIONS 

//  . . * . . . . 

void  initamPageModule () ; 

•endif  //  _myKeyModule 


•include 

•include 

•include 

•include 

•include 

•include 

•include 

•include 


’ amPageModule , h* 
"bbKeyboard.h" 
"bbEventResponse.h" 
"bbCallback.h" 
"bbModule.h" 
"bbMouse . h* 
"npsWindow.h* 
"npsViewport . h" 


ft  ••***•• 

/ /  CODE 
//  . 


//  . . . . . . 

//  Function  Name:  initamPageModule ( ) 

//  Task:  initialize  Module  --  this  is  run  only  once 
//  sets  up  keyboard  callbacks 
//  Return  Value:  void 
//  . * . * . . 


void  initamPageModule () { 

void  loadFunc (bbObject  "object,  bbData  ‘data) ; 
void  unloadFunc {bbObject  "object.  bbData  *data); 

bbKeyboard  "keyboard; 

bbEventResponse  "eventResponse; 
bbCallback  "callback; 

keyboard  =  bbKeyboard: : get Instance () ; 

//  load  module  key 

eventResponse  =  new  bbEventResponse (bbKeyboard: :KEY_L  | 
bbKeyboard:  :CTRL_MASK  |  bbKeyboard:  :DOWN_TRANS)  ; 
callback  =  new  bbCallbackO; 
callback->setFunc( loadFunc) ; 
entResponse->addCallbackLast (callback) ; 
keyboard->addEventResponse (eventResponse)  ; 

//  unload  module  key 

eventResponse  =  new  bbEventResponse  (bbKeyboard:  :KEY_U  | 
bbKeyboard:  :CTRL_MASK  |  bbKeyboard :: DO WN_TRANS )  ; 
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callback  =  new  bbCallbackt) ; 
eallback->setFune (unloadFunc) ; 
eventResponse->addCallbackLast (callback) ; 
keyboard->addEventResponse (eventResponse) ; 

}//end  initamPageModule 


//  Function  Name:  loadFunc 0 

//  Task:  callback  function  chat  loads  modules 
//  Return  Value:  void 


void  loadFunc (bbObject  ‘object,  bbData  *data) { 
int  mouse InWindow () ; 


char  modu 1 eName 164); 
char  ‘ptr; 


cout  «  ‘LOAD: Please  enter  the  module’s  name  :  *  «  flush; 
cin  »  moduleName; 
cout  «  endl; 

if  ( istrncmp (moduleName,  "http://",  7))  ( 

ptr  =  moduleName  «■  7;  //  skip  over  http:// 

ptr  =  strrehr (ptr,  ’/’);  tt  make  sure  url  well  formed 
if  ( !pcr) { 

cout  «  *  myDynamicPageModule:  Bad  command  line  parameter.' 

endl ; 

cout  «  m  myDynamicPageModule :  URLs  must  be  formatted  as 
\*http: //<host> (/path) /moduleName\ "  “  «  endl; 

cout  «  *  myDynamicPageModule:  Example:  bamboo 
http: / /watsen. net /Bamboo /Modules /myRemoteModule"  «  endl; 

cout  «  endl; 

} 

•per  =  " \0 ' ;  tt  efficient  hack 

if  (  * (ptr+1)  ==  *\0'){  It  module  can  not  be  index.html! 

cout  «  "  myDynamicPageModule:  Bad  command  line  parameter. 

endl; 

cout  <<  *  myDynamicPageModule:  URLs  must  be  formatted  as 
\ "http : //<host> [/path) /moduleName\"  “  «  endl; 

COUt  «  *  myDynamicPageModule:  Example:  bamboo 
http://watsen.net/Bamboo/Modules/myRemoteModule"  «  endl; 

cout  «  endl; 

} 

if  ( ! bbModule: : load (ptr*l ,  moduleName) ) { 

•ptr  =  ’/*;  //  put  it  back 

cout  «  "  myDynamicPageModule:  Unable  to  load  *  <<  moduleN. 


{  //  must  already  be  on  disk 


window  =  npsWindow: : f indObj  ect ( "AdminWindow"  ) ; 
viewport  =  npsViewport: : f indObj ect { “AdminViewport* ) ; 
float  x,y; 

x  =  bbMouse : :getX { ) ; 
y  =  bbMouse: :getY() ; 
bbScreen: :normalizeVal (fcx, fcy) ; 


if (window) ( 

if  (viewport->getWindow( ) ->isValInside (x, y)  ) ( 
flag  =  1; 


if  (! bbModule :: load (moduleName,  0} )  { 

cout  «  “  myDynamicPageModule:  Unable  to  load  *  ■ 


) //end  if 
}//end  loadFunc 


//  Function  Name:  loadFunc () 

//  Task:  callback  function  that  unloads  module: 
//  Return  Value:  void 


roid  unloadFunc (bbObj ect  ‘object,  bbData  *data){ 
int  mouselnWindowO; 

char  moduleName ( 64] ; 

bbModule  ‘module; 

if (mouselnWindowf ) > { 

cout  «  "UNLOAD: Please  enter  the  module’s  name  :  *  «  flush; 
cin  »  moduleName; 
cout  «  endl; 

module  =  bbModule :: f indObj ect (moduleName)  ; 
if  ( ‘module) ( 

cout  «  ■  myDynamicPageModule:  specified  module  \"*  «  moduleName  • 
’  is  not  currently  loaded. .. ignoring"  «  endl; 
return; 


if  ( (bbModule: : unload (module) ) ( 

cout  «  "  myDynamicPageModule:  Error  unloading  "  «  moduleName  - 

cout  «  "  Fatal  Error  -  aborting  executable!"  «  endl  «  endl; 
exit (0) ; 


) //end  if 

)//  end  unloadfunc 


//  Function  Name:  mouselnWindowO 

//  Task:  tells  if  mouse  is  in  the  correct  window  to  receive  keyboard 
/ /  commands 

//  Return  Value:  int  representing  boolean 


int  mouselnWindowO  ( 
int  flag  =  0; 


npsWindow 

npsViewport 
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APPENDIX  C:  GLOSSARY 


attribute 

•  A  named  portion  of  an  object  state, 

event 

•  A  change  of  object  attribute  value,  an  interaction  between  objects,  an 
instantiation  of  a  new  object,  or  a  deletion  of  an  existing  object  that  is 
associated  with  a  particular  point  on  the  federation  time  axis.  Each  event 
contains  a  time  stamp  indicating  when  it  is  said  to  occur  (also  see  definition 
of  message). 

federate 

•  A  member  of  a  HLA  Federation.  All  applications  participating  in  a 
Federation  are  called  Federates.  In  reality,  this  may  include  Federate 
Managers,  data  collectors,  live  entity  surrogates  simulations,  or  passive 
viewers. 

federation 

•  A  named  set  of  interacting  federates,  a  common  federation  object  model, 
and  supporting  RTI,  that  are  used  as  a  whole  to  achieve  some  specific 
objective. 

federation  execution 

•  The  federation  execution  represents  the  actual  operation,  over  time,  of  a 
subset  of  the  federates  and  the  RTI  initialization  data  taken  from  a 
particular  federation.  It  is  the  step  where  the  executable  code  is  run  to 
conduct  the  exercise  and  produce  the  data  for  the  measures  of  effectiveness 
for  the  federation  execution. 

Federation  Object  Model  (FOM) 

•  An  identification  of  the  essential  classes  of  objects,  object  attributes,  and 
object  interactions  that  are  supported  by  an  HLA  federation.  In  addition, 
optional  classes  of  additional  information  may  also  be  specified  to  achieve  a 
more  complete  description  of  the  federation  structure  and/or  behavior. 

interaction 

•  An  explicit  action  taken  by  an  object,  that  can  optionally! within  the  bounds 
of  the  FOM)  be  directed  toward  other  objects,  including  geographical 
areas,  etc. 

message 

•  A  data  unit  transmitted  between  federates  containing  at  most  one  event. 
Here,  a  message  typically  contains  information  concerning  an  event,  and  is 
used  to  notify  another  federate  that  the  event  has  occurred.  When 
containing  such  event  information,  the  message's  time  stamp  is  defined  as 
the  time  stamp  of  the  event  to  which  it  corresponds.  Here,  a  "message" 
corresponds  to  a  single  event,  however  the  physical  transport  media  may 
include  several  such  messages  in  a  single  "physical  message"  that  is 
transmitted  through  the  network. 


model 

•  A  physical,  mathematical,  or  otherwise  logical  representation  of  a  system, 
entity,  phenomenon,  or  process.  [DoD  5000.59] 

object 

•  A  fundamental  element  of  a  conceptual  representation  for  a  federate  that 
reflects  the  "real  world"  at  levels  of  abstraction  and  resolution  appropriate 
for  federate  interoperability.  For  any  given  value  of  time,  the  state  of  an 
object  is  defined  as  the  enumeration  of  all  its  attribute  values. 

object  model 

•  A  specification  of  the  objects  intrinsic  to  a  given  system,  including  a 
description  of  the  object  characteristics  (attributes)and  a  description  of  the 
static  and  dynamic  relationships  that  exist  between  objects. 

object  model  framework 

•  The  rules  and  terminology  used  to  describe  HLA  object  models. 

object  ownership 

•  Ownership  of  the  ID  attribute  of  an  object,  initially  established  by  use  of 
the  Instantiate  Object  interface  service.  Encompasses  the  privilege  of 
deleting  the  object  using  the  Delete  Object  service.  Can  be  transferred  to 
another  federate  using  the  attribute  ownership  management  services. 

Runtime  Infrastructure  (RTT) 

•  The  general  purpose  distributed  operating  system  software  which  provides 
the  common  interface  services  during  the  runtime  of  an  HLA  federation. 

simulation 

•  A  method  for  implementing  a  model  over  time.  Also,  a  technique  for 
testing,  analysis,  or  training  in  which  real-world  systems  are  used,  or  where 
real-world  and  conceptual  systems  are  reproduced  by  a  model. 

Simulation  Object  Model  (SOM) 

•  A  specification  of  the  intrinsic  capabilities  that  an  individual  simulation 
offers  to  federations.  The  standard  format  in  which  SOMs  are  expressed 
provides  a  means  for  federation  developers  to  quickly  determine  the 
suitability  of  simulation  systems  to  assume  specific  roles  within  a 
federation. 

time  management 

•  A  collection  of  mechanisms  and  services  to  control  the  advancement  of 
time  within  each  federate  during  an  execution  in  a  way  that  is  consistent 
with  federation  requirements  for  message  ordering  and  delivery. 
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